Guidelines for testing

I'm really not fond of forcing someone to do something. Make someone do something while they're not agreeing is like giving vegetables to a dog and force it to eat it. If you take a look at the picture, NASA is also testing their parachutes. They don't do that for fun! Sometimes tests are necessary.

As you can see in some of my previous posts I didn't like unit tests at all. That was 6 or 7 years ago. Back then it was no use forcing me to create unit tests, because I was constantly looking for a way to avoid them. And that worked quite some times. You can force someone to do things, but he will do it without putting his mind to it and so the result must be a pale shadow of the result you are trying to achieve! In my opinion, the only thing we can do about it is make it fun, or make it a challenge.

Guidelines for testing (from a developer perspective)

1. All the code you added or updated should have a 100% test coverage.

You can read this as: aim to get a 100% coverage on you code. Don't be too easy on the percentages! I know there is tooling that can help you with that.

1. When you are working with legacy code with lots of nested loops or if-statements, try to put some end-to-end or integration tests around it. Then try to refactor it carefully. And finally create the unit tests that cover your new mutations. They will fail if you do it TDD and you can start on the real implementation.
2. An other option is perhaps creating a class with only the functionality or business rules you need to implement and try to inject it or instantiate into the 'old' class. You can test then if it is instantiated and you can test the class all by itself.
3. If you are working in source code that is suitable for unit tests, go TDD on it. So first create your unit tests and then go ahead and make your implementation. And remember, you almost always have to refactor the original code. Get the clean class clean again!

Note: TDD is something you have to learn. It's not something you can master instantly, so experiment with it a lot!

Note: If you come across too much variety to test your unit to create a 100% coverage, then you should ask yourself if your unit is indeed one unit and not multiple ones in one.

2. Collaboration before and during the user story between testers and developers.

It's very important to make a deal between developers and testers on what the test approach will be. I think you can predict quite good what tests there will be or must be written. Try to get synergy out of it so that the tester tests not the same tests as your automation tests. Of course, if you decide to have it tested both automatically and manually, you should do so. Write down your scenarios and try to come up with deviations and variations. Talk about:

1. Unit tests. As a developer, try to make it clear to the tester what your units look like and how you think you can test them. Business rules are of course perfect examples to talk about. Try to find out what the need is for unit tests and maybe the tester can point out some unhappy paths you didn't think of.
2. Integration tests. Try to use a Gherkin tool test environment. Something like SpecFlow, Fitnesse or Cucumber. You can use only functional sentences in here, so no class names, properties or arguments! Be clear on what your new functionality does and why it's there. Use the common way where you point out who the user is, what he wants and especially why he wants it. 
3. End-to-end tests. You have at least one end-to-end test to make sure the user interface works correctly. One happy path should probably suffice.

Note:Run these tests each in a different rate! you should not overload the build server by running all of the tests always. The rate should be something like: Unit tests: always, every build. Integration tests: twice a day. End-to-end: once a day, maybe at night. There is always the possibility to consider running all of them locally of course.

3. 10-20-70

These are the percentages for these 3 kinds of tests. End-to-end: 10%, Integration: 20% and unit tests: 70%. This is a recommendation of course, but try to monitor at the end of each iteration or two what the percentages are. If you end up with 60% end-to-end tests, something's wrong. The same for extreme deviations in the other type of tests.

4. Code coverage

Code coverage will help you to see where you, as a developer, dropped one or more stitches. Keep in mind that common sense prevails! You are in charge of the tool and not the other way around. Use it to make sure you covered your code well enough. Of course in consultation with the tester.

Conclusion

Don't consider not making tests! You benefit from them too much! At first glance you think they disturb your coding process, but (this is a fact) they help you code the right way and they will give you a higher speed!

Also, read the clean code book from Robert Cecil Martin (uncle Bob) or watch his video's (they are fun to watch). They help you understand why it is inevitably to always have tests and what happens if you don't! Or you should do a test like a code kata on two groups. Let them separately work on software that constantly needs changes. You'll see what happens! 

Note: Learn from all your experiences and keep steering to the right direction!