Tar Pit stories

Hi, Following the previous post topic regarding building your own solutions when using a package or framework is not an option, I proceed to show how CITestCase looks: The Unit Testing bespoke solution abstract class CITestCase { private $printer = null; public function __construct(OutputPrinter $printer) { $this->printer = $printer; } abstract protected function setUp(); abstract protected function tearDown(); public function run() { $results = []; $me = new ReflectionClass(get_called_class()); $batch = array_filter($me->getMethods(ReflectionMethod::IS_PROTECTED), function(ReflectionMethod $method) { return preg_match('/Test$/', $method->getName()) === 1; }); /* @var $testMethod ReflectionMethod */ foreach ($batch as $testMethod) { $this->setUp(); $results[] = ['name' => $testMethod->getName(), ...

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 frame...

Hi, Today, when I was revising some classes of our messy code base, it caught my attention this comment of one of my former teammates, who recently left: Back in June 2016, when he was actually performing a refactor of the same code base, he wrote TESTS PENDING into a commit, bearing in mind to create some unit tests after the refactor. Unfortunately, we know we never come back. And this is something we all have gone through. Some of the important bits that Martin Fowler and Kent Beck encourage to do when performing refactors of legacy code is to move on bit by bit, small changes along with unit tests. [ Refactoring ] After a massive refactor, they also point out, it's very difficult to keep track of all the changes in case we break the code, and as a consequence, reverting our changes is necessary. Performance gains when shorts steps are taken since we minimise the time of reverting newly introduced bugs or rolling back due to undesired side effects. In short...

Hi there, It is my aim to write a series of articles based on my personal experience on programming from now on and, why not, maybe from my past as well, about coding and related activities. The approach I'd like to take is about experiences, either good or bad ones. And about any interesting code snippet I may have come up or come across. My linkedIn introduction My name is Víctor Molero, 40yo, father of two children. I'm passionate about building (or refactoring) software to a high quality standard by using proven good practises. My background is made up of a Computer Science Bachelor, 15+ years of experience working with a wide range of technologies and a special care to the detail on my day by day work. LinkedIn profile:  https://www.linkedin.com/in/vicjmt/?locale=en_US Thanks I'd like to thank  Sandro Mancuso , whose book " The Software Craftman ", enlighted me to start writing for the community to spread my (little) wisdom. Spreading ...