First published on blog.dvlup.com

Most developers have at some point in their career of building software solutions come across unit testing. There are a variety of reasons why you start using unit testing. In some cases it is a matter of necessity to sort out what works and what doesn’t in a legacy project you are taking over. It could be a client requirement to meet a particular quality requirement for delivery, it could be an internal policy to keep software maintainable or meet a certain KPI (shudder!). Whether you current project is, don’t be mistaken: Unit testing could save you both time and money. In fact it is extremely likely it will.

In all of the projects I work on now, there is a very clear line of when I choose to use unit tests. If I am building a production ready product, there is no question. Unit tests are a first class citizen from the beginning. If I am building a prototype to test a technology or prove a point, I use unit tests more liberally in areas that have great importance. In either case I always implement unit tests, because they make my life easier. And as a developer I am inherently lazy, so anything that make my job easier I will use.

We have established that you should always use unit tests, but why? Although the aim of this article is not to teach you how to write unit tests (there are plenty of resources on this), it is worth noting the reasons for including them.

• Quick way to identify logic errors in code. Even if your code compiles, it does not guarantee that the logic is correct.
• Details change daily, but the sentiment rarely does. Your product is a living being, and you will make changes to it all the time. However, existing features should remain consistent.
• Allows you to make big changes to code quickly. Your functionality can be tested quickly at every step of the change.
• Refactor with confidence. Code wide refactoring can be done quickly using your favourite code refactoring tool, and then unit tests can verify the legitimacy of the changes.
• Instant visual feedback. You can run unit tests automatically as part of your build process and the results can be displayed on a dedicated screen.
• Red means broken, green means go. Quickly identify where an error is by looking for failed tests.
• Great unit tests can help document code. Often unit tests will tell a story if done appropriately. This will help any future developers understand the code quicker and with more confidence.
• Improves coding efficiency. Adding unit tests to a project does not mean writing the code twice. Because you know what the code should achieve you will get there faster.

Any of the reasons above can be applied to most projects, and even if you are just a single developer, don’t think it is only for larger projects. Writing apps for Windows Phone is often a single resource project, but all of the above points still apply. You might think you know the code intricately, and you most likely do, but when you finish the project and don’t look at the code for 6 months, unit tests can help you can back on the horse quick smart.

How Do You Identify Test Cases?

Unit tests are there to confirm your logic and to give you confidence that your code is solving the problem you set out to. But how do you know what to unit test and what to leave? You shouldn’t unit test every single aspect of your project, as that is highly inefficient and a lot of tests will be unnecessary.

In general the areas to test are

• Domain logic. Any calculations or workflow logic you have should be unit tested. The same goes for any business values that affect your application.
• Application specific areas. If an area is specifically used only in your application logic, make sure it is tested thoroughly. You won’t be able to rely on built-in functionality if you have built it all yourself.

Likewise there are some areas you shouldn’t test.

• Framework functionality. If you are using a framework, such as the .NET framework, don’t test it. Whoever built it, i.e. Microsoft, have done a lot of testing before releasing it. This includes generic collections, web handlers, I/O functionality etc. Always assume that a framework is working as expected.
• Testing across layers. Don’t test across logical layers, such as between database and business logic. This falls under integration testing and is a whole other area of testing.

Keeping Unit Tests Alive

The most important thing when it comes to your unit tests is that you love them. Care for them and give them plenty of attention. Don’t leave them in the corner to face into obscurity, because you might as well not have created them in the first place.

Unit tests are first class citizens and must always be treated as such. If you change code involving one or more tests, make sure you update the tests where necessary as well. Broken tests must be fixed and not just commented out and forgotten. Unloved tests will almost certainly come back to bite you.

If you want to know more about unit testing, integration testing, performance testing, error management and much more in that area for Windows Phone, watch my latest Pluralsight course on the topic, Windows Phone Testing and Error Management. It will make your app robust, reliable and successful.