Rad Coding

The repetition problem Some time ago I had a chance to witness the truth of this universally applicable sentence on a set of integration tests. Our integration tests were taking definitely longer than we expected them to and it was hard to pin to down the exact few cases, which were driving the performance of the whole test set down. After looking at the tests, I noticed some suspicious lines of code in the test setup (we were using SpecFlow): If you’re familiar with SpecFlow, maybe you've already noticed the issue. There’s a common rule taught to all young programmers: if your program is going to use a calculated value multiple times, be sure to calculate it just once. If we translate the previous example from SpecFlow to nUnit Framework, it would look similar to that: This code does the all the initialization before every test being run, multiplying the work by the number of tests. However, being hidden behind a neat attribute, it’s easy to be overseen. Know yo...

“Technical Debt” is one of the most often encountered problems in software development. Whether it’s written by the previous owners of the code (damn them!), your team (ehhh…) or you personally (ooopsie), it’s one of the typical things we encounter during our work. I have a feeling that there’s an urge in most of the developers (including me) to adjust and improve existing code. It’s definitely easier to later understand the code, if it’s written in a more readable and well tested way. But how to measure if it will be worth the time invested? Refactor - Invest time now to save it later Refactoring can have different goals and it’s important to keep in mind what we want to achieve with changing existing, working code. In the end, however, the idea is to invest some time now, so that we can later spare even more time. After all, the goal of every project is always to fulfil a business goal with a minimal amount of resources. The faster/cheaper it is done, the more advantage it giv...

Test Driven means great! The aim of Test-Driven Development (TDD) is to minimize the number of mistakes in the code by forcing the developer to analyze the test cases before writing the code. Its main value comes from engaging the programmer in considering all the use cases before writing the production code. The traditional process of writing code using TDD involves following steps: Plan what you want to do! (What’s given? What’s the result?) Write your test! ( Arrange/Act/Assert ) Realize the test fails… Make it green (by writing your code) Then follow the aforementioned steps until your functionality is implemented. The obvious drawback is that it takes time to think of the test cases, so the implementation process is slower than writing the same code without TDD , which again is slower than writing the same code without writing any tests, which is again slower than not testing your code at all… There is a pattern to be seen there. It may be consid...