Yes, you can!! Part I

Hi there,

Does it ring a bell those situations where you need a new functionality for your code and you cannot use third party software straight off? 

A quick assessment along with a decision has to be made quickly in order to either doing something from the scratch (in a decent time) to fit the needs, or go through a tough process of adapting the legacy old code base to make it compatible with the third party system.

Both situations imply risks and you have to reach a trade-off depending on the context. By and large, we are so used to rely on frameworks and packages that encapsulate some kind of feature, that we become lazy when it comes to build something we know it already exists, so our first approach is to try to adapt. 

Since CodeIgniter (CI) turns out to be unfriendly in terms of testability, adopting the PHPUnit framework becomes an unpleasant task. Given my company current context, going through a massive change of the framework core is simply not an option, so, eventually, I had to face the initial option, aka DIY. 

Despite the fact that we may have a terrible feeling of reinventing the wheel (in other words, a miserably waste of time), surprisingly, we very quickly realise that, actually, what we need is just bit portion of the whole 3rd party package functionality so far.

Being myself into the quest of being a better professional, I decided to build my own custom php-unit micro framework to proceed with code refactors.

Folder structure



The core is made up of two classes: CITestCase and the basic HtmlPrinter (implements OutputPrinter) for showing the tests results. Since we need the CI framework to bootstrap through index.php, the application entry point is a Test controller, accessed via HTTP request:

/test/module/run

Go to Part II

Comments

Post a Comment

Popular posts from this blog

Bulk Inserts and the Performance Holy Grial (Part II)

Hi, Back to our topic ( see previous post ) about bulk inserts using PHP and Oracle OCI library, the first approach I'll explain today is as follows: Public method bulk_insert public function bulk_insert($common, $data) { try { $params = $this->prepareBulkInsertParams($common, $data); return $this->ociBulkInsert($params); } catch (Exception $e) { $this->logger->log(ERROR, $e->getMessage()); } } Neat, isn't it? At a first glance, a much clearer method is the result of a first refactor. Many of the code pieces have been extracted to a new method ( Extract method , Refactoring, K. Beck) alongside with new ones to give support to the PL/SQL batch insert syntax. Preparing the Parameters This method is just for extracting the incoming data and transform it into a more manageable array. private function prepareBulkInsertParams(array $common, array $data) : array { ext...
Keep reading

Legacy code concepts II: the Seam Model

Hi audience, According to my last post, there are some important concepts related to legacy code that it is worth writing down and, therefore, have a clearer picture. Sensing and separation were two of them, both concepts tightly related to breaking dependencies. Moving forward, in line with those, I’m going to write about the Seam Model, introduced by Michael C. Feathers in his book Working Effectively with Legacy Code . The Seam Model The Seam Model is a convenient name to represent the ways by which we can perform tests without producing code changes in order to get a class into a test harness. A Seam Quoting the author, “A seam is a place where you can alter behaviour in your program without editing that place” Important to highlight: alter behaviour without editing . So how can we change behaviour without changing the code? We can actually do it in different ways or manners so far: Seam types Preprocessing seam : used in languages that allow preprocessing, such as C+...
Keep reading

Bulk Inserts and the Performance Holy Grial (Part I)

Hello, I've been asked to improve a part of a model class which is causing some database issues. We use PHP and Oracle, so our legacy code is built using the OCI ( Oracle Client Interface) built-in library to take advantage as much as possible of the driver speed instead of using either the CodeIgniter abstracted database class or, simply, PDO ( PDO for Oracle ). Since we have to deal with bulk transactions under high load scenarios, database access optimization is a must. Massive rows have to be inserted prior to another batch of updates on them lately. Binding parameters in advance is a way of getting a performance improvement (read more on this topic here: https://blogs.oracle.com/sql/entry/improve_sql_query_performance_by ), in addition to avoid SQL injection attacks. So, here's is a snippet of what the bulk insert method looked like before any change: class TxnUser extends CI_Model { const OPEN = 1; const CLOSED = 0; [...] // Legacy meth...
Keep reading