Over a million developers have joined DZone.

5 Signs You're Thinking About Testing Incorrectly

DZone's Guide to

5 Signs You're Thinking About Testing Incorrectly

Testing is incredibly important to the DevOps way of thinking. Here are some common ways of thinking about it that should be forgotten.

· DevOps Zone ·
Free Resource

Deploy code to production now. Release to users when ready. Learn how to separate code deployment from user-facing feature releases with LaunchDarkly.

Test runner output showing both passing and failing tests

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.

Deploy code to production now. Release to users when ready. Learn how to separate code deployment from user-facing feature releases with LaunchDarkly.

testing ,development patterns

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}