5 signs you're thinking about testing your code incorrectly

Having code that can be tested in an automated way is essential when it comes to making software that you can support and update quickly. Unfortunately there are still many developers for whom testing isn't a priority or even a consideration :(

Here are five indications that you're not prioritizing testing appropriately as a developer, and the consequences thereof:


1. Waiting until the code has been written until thinking about how it will be tested.
If you wait before planning and writing your tests you'll probably find that: you haven't structured your code in a way that makes it easy to test; and you're running low on time and so might think that you haven't got time to write tests. Of course, this ignores the fact that having good automated tests means that you'll save time over the life of the code.

2. Relying on others to write tests or do the testing.
Involving more people in the process of developing software slows the process by increasing the communication overhead. More importantly though, when a developer is not responsible for testing their code it dissolves them of some of the responsibility of making sure that is it correct. It often also creates a scenario where they don't know what the software should fully do in all cases or all the scenarios it has to support. If they don't know this upfront because they don't have to test for it it's also more likely that they won't code for it either. In turn this leads to more work and takes longer.
This also has many of the same side effects of waiting until the code has been written as it's hard for someone else to be testing the code while it is being written.

3. Relying on manual testing.
Manual testing is much slower than running automated tests. Manual testing is also more error prone and more expensive to scale.
There are some forms of testing (e.g. exploratory testing) that are much better done by actual people. By automating the tests that are predictable and repetitive it frees up manual testers to focus on the things that people do best.

4. Blaming a lack of tooling (or tooling limitations) for not writing tests.
Particularly when working with newer languages, tools or frameworks a lack of test tooling can limit the ways that code can be tested. This is also true of code that runs in a restrictive environment, such as a sandbox, on a phone or other dedicated hardware device. If this is the case then this can be addressed by moving as much as possible into a library (PCL?) that can be run in an environment where tests can be easily run. This may mean that some of the platform specific parts of the code need to be abstracted and that some parts must still be manually tested. Sometimes such things can't be avoided. Taking a pragmatic, compromising, approach can still allow you to get many of the benefits of automated testing. It may be a little more work but it's worth it for the benefits that are possible.

5. Not knowing what to test.
Not knowing what to test is a sign that it's not known what a piece of code, or application, should do or what all its capabilities should include and exclude. Without this knowledge there's a strong argument that it shouldn't be possible to correctly build the software in the first place.
Related to this is not knowing where to start in terms of adding tests to an existing project. In such a situation you should be focusing on the parts that are the most: important; complicated; and/or error prone. This creates the greatest way of gaining value from a small number of tests.