1. Given When Then Scenarios vs Test Fixtures

    By Shaun Finglas

    There are two common ways of writing automated tests which apply from unit to acceptance tests. These are typically known as test fixtures and Given-When-Then scenarios.

    Test Fixture

    • Traditional method of writing tests.
    • The common JUnit/NUnit approach. Other languages have very similar concepts.
    • Single test fixture with multiple tests …
  2. Foreign Key Constraints and Microservices

    By Shaun Finglas

    Database constraints when used in relational databases are great. They ensure data integrity at the lowest level. No one would argue against using them in practice. Essentially constraints can be thought of as assertions against your database. Rules such as requirement, default values and foreign key constraints double check your …

  3. Past Mistakes - Out of Process Commands

    By Shaun Finglas

    Some of the best lessons you can learn are from failure. I figured a series on mistakes I've made in the past would highlight where I went wrong and more importantly what to remember going forward. These real life examples vary from my early days of programming all the way …

  4. You Rarely Need Custom Exceptions

    By Shaun Finglas

    Implementing custom exceptions usually gives a hint as to why you rarely need custom implementations. They are often nothing more than sub classes where the only difference is the type name and containing message.

    In this C# example there is a lot of code for nothing. When checking logs or …

  5. Your Job Isn't to Write Code

    By Shaun Finglas

    Solving problems is the role of software developers first and foremost. The most interesting aspect is that in many cases it is possible to perform this role without writing a single line of code.

    Low Tech

    I once worked with a digital dashboard which monitored applications. One of the yet …

  6. Legacy Code is Just Code

    By Shaun Finglas

    Try and define legacy code. Working Effectively With Legacy Code states it is simply code with no tests. This is an almost perfect definition, however it is quite easy to have code that is covered by automated tests, yet is still considered to be legacy. Poor quality, or missing test …

  7. Project Setup Tax

    By Shaun Finglas

    With microservices gaining popularity, one consideration prior to adoption is new project setup. In fact this statement holds true for any new project that you decide to create.

    Each new project requires at a minimum

    • Source control - somewhere to actually store the code.
    • A project base - API, executable, library, application …
  8. X% of Configuration is Never Used

    By Shaun Finglas

    Code configuration is essentially for the likes of URLs, credentials or other per deployable settings. Sadly configuration seems to fall into examples where there is simply too much configuration, or the system has so many configuration points the actual code becomes far too complex for its own good.

    Too Much …

  9. Pulling the Plug on Date Time Parsing

    By Shaun Finglas

    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 …

  10. Best of Breed

    By Shaun Finglas

    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 …

« Page 3 / 13 »