Skip to main content

Posts

Showing posts from March, 2016

Pulling the Plug on Date Time Parsing

Date/time logic is hard. Throw in time zones along with daylight saving and it's even harder. Recently a suite of tests that had happily been running for months started failing. There were no code changes and all the tests were somehow related to date/time ranges.Despite this the production code was functioning as expected. It turns out the API was explicitly setting the locale to use en-GB. However the suite of tests were not. The fix was simple. Prior to the test fixtures executing, explicitly set the locale. In order to test this assumption and see the tests pass, a temporary change on the development machine was required.The locale was set on the development machine to another region. In this case setting to en-US was enough to cause the tests to fail. After the code change the tests passed. Any locale can be used as long as the date format differs.This idea is pretty easy, and is very close to my technique of pulling the plug on automated tests. The test suite can now be run …

Best of Breed

Spikes are one of the best ways to aid the design of software. In some cases spike solutions can open more questions than they solve. The use of a technique known as Best of Breed can assist when this arises.Rather than producing a single spike, produce several. Either individually or with other developers working on a spike each. Each solution can then be compared and contrasted. The best parts of each solution can then be combined. Best of Breed is named for its likeness to genetics where the best genes win out for future generations as part of the process of evolution.ExampleSpike solution A has an excellent way to handle future requirements due to the open and closed approach taken. Solution B solves the data access problem in an elegant manner. Both solutions have good components. Simply combine the solutions into a single approach. This results in code that contains extensibility and good data access patterns.BenefitsNeither standalone solution would have been as good as this hy…

Singleton's and the Singleton Lifestyle

The death of testability and the lack of isolation make the singleton pattern a relic of times gone by. Rarely have I had a real need to code a singleton since my first year of university. Most decisions to use a singleton boil down to scoping issues.SingletonAssume a game requires a single instance of a rendering component. In this example configuring and initialising the renderer may be expensive. We only want to do this once.While this singleton renderer solves the problem of instantiating more than once it suffers from the fact there is only ever one instance. If we want multiple renderers such as a console debugger we are out of luck. Testability is also lost. If we wish to exercise the Game, we need to provide and use a real rendering component.Static ClassesOr class instances give you the same advantages and disadvantages of singletons. You only have one instance and you can access it easily. One big difference is that unlike singletons you cannot provide static instances as ar…

Eating your own Dog Food

Also known as dog fooding. It's an odd term, with roots dating back to 70's adverts and the even more bizarre. In software development the idea is simple. Use the software you produce to make it better. This can be taken to the extreme with examples such as Notepad++ being built with Notepad++, or the Github team using Github internally. These examples mean the product is as good as it can be from real life use.API'sDog fooding works great for APIs. When the boundary of a system is an API building a fake test UI is a wise move. This integration acts as if you were the user. If you can solve the basic uses cases that your integrators need you can be confident the API is fit for purpose. Integration highlights problems and areas for improvement. Building a test UI is a very easy step to carry out which is also useful for demonstrating and documenting the API to others.The danger of not eating your own dog food when producing APIs is detachment from what your users will be tr…

Write Assertions First

Writing a test as part of the TDD process is simple.ArrangeActAssertMany individuals recommend the process be reversed. Write assertions first. Then write the steps to perform the action. Followed by the required setup to complete the action.ArrangeActAssertSimplicityYou will write just enough of the test to do the job. Its not far from doing TDD on the test itself. Using staticily compiled languages you would see compile time errors while performing this step. As you are writing the test in reverse this is normal and expected. Most text editors or IDE's can ease this process.Implement just enough of the test to do your job. The opposite of this is large, copy/paste tests that require lines of setup code that can safely be removed or reduced.MeaningYou end up naming variables with more meaning. With a traditional approach variables can lack true, descriptive names. They are often called result or similar. By working in reverse you force yourself to think of what you are asserting …