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!

Traffic jams

Let's talk about traffic jams. You know the rubber necking, when you are staring at the car in front and wave to the one next to you. Always curious what kind of men or women are also joining you on the highway? And you begin to wonder, why do I have to go through this almost every morning and afternoon? Does it make me glad to be on the road, or does it make me real mad? Let's ask ourselves a couple of other questions first.

First question is: what causes traffic jams?

You know that when one car reduces speed, the traffic behind that car reacts on it. So in short, if one car or more hit the breaks, even if it is a mild break, the cars behind these vehicles also hit the breaks. And most of the time they hit the break harder than the car in front, especially when they are close to each other. The smaller the distance between the cars, the greater the effect will be and the more likely there will be a traffic jam. Also when you are a not predictable vehicle, like when you're changing lanes a couple of times, you affect the other drivers as well and there it goes again.

Second question is: how can we stop the traffic jams?

The first answer is: if you, as a participant of the traffic jam, try to remain a constant speed, the traffic jam will dissolve. The second answer is a supplement of answer one: try to avoid making other car drivers nervous by not making sudden moves to the right or left. That will of course because car drivers hit the break and you start the effect all over again.

Third question is: how can we prevent traffic jams?

Sure there will be trouble on the road. There always will be! For instance, someone having a flat tire, or a bike falls off a car. Someone gets unwell.

So one truth in that is that you can never hold back the traffic jam for ever. So what do we need to do then? We can have less cars on the road, so it get's more containable or, like Google, have cars interact on each other and let the car do the driving for you. More alerting systems will help too. Drive steady and not with fluctuations. We can summarize this in one word: control! We do need more control on the road.

Why do I write a blog about traffic jams?

The first answer (just to stay in tune with the previous questions) is: it's fun! Second answer is: you probably know what I'm talking about! But let's see if you come up with the same comparison as I do.

The cars are the functionality that needs to be taken to the customer. The teams are steering the car. The stakeholder and managers are the people who want to get the drivers move faster on their project. They see gaps between the lanes next to the car and tell the driver to take that lane to speed up the project. So they are maneuvering the teams through the traffic. And if you tell the driver speed up, you are about to let him make more mistakes. The thing to do here to prevent traffic jams is to instruct the driver how to drive. Also the driver clearly has an appointment! If you need to travel more distance than you expected, or have less time then you expected then you logically have the urge to go faster. So maybe you had to schedule it for some time later, or should have hit the road much earlier. Be prepared! Take control! Just be sure you remain driving steady at your familiar speed.

So, do I feel happy on the road?

Maybe we need to ask ourselves: are we happy on the road? And furthermore, is the customer happy to have to wait for their functionality, because we didn't make it in the time we scheduled. Or if we do have it delivered in time, are they happy with a wreck then? Maybe we should also think about what the costs will be when we crash, for example the emergency services, the damage and the settlement with insurance companies. Your car can be prepared, but it will be lower in value.

Next post, coming up!

It’s so nice to talk in metaphors when you have such a vague subject to discuss about, you know! The next post I will publish will be about: how to control your projects and sprints and that one will be quite specific and not vague at all. Thanks for reading this through to the end. I hope you enjoyed it. And remember to comment beneath this post if you have any questions or submits.

By the way: in the Netherlands, the maximum speed is recently changed at some sections from 120 to 130 kilometers per hour. So keep in mind that we can change the speed, but we have to make sure we still don’t have fluctuations in speed and we have to make sure we make our goal in a well chosen time! Remember: it's all about control!

No testing? What?

Create code without unit tests? No integration tests as well? And no end-to-end tests?
Let's first start with unit tests. What kind of programmer are you when you produce no unit tests? Are you not feeling responsible for your creations?
Mmm, I think I went off the wrong foot here, maybe I shouldn't start off with accusing people. Maybe I should start just with myself, some years earlier.

When I was younger...

Man, did I hate unit tests for 6 years ago! Really, I disliked them a lot and I never created them! Boy was my code rotting back then. Maybe it was because someone figured out creating unit tests was mandatory? When it's obligatory to do something, when you are judged on it, you get an aversion on it. No one needs to tell you what to do, right? It's stupid someone needs to tell you how to develop! And I think you're right about that! Congratulations! You are the best developer ever! 

Turning point?

And at this point you suspect me to I turn this euphorically feeling about the pigheaded developer, who has enough experience to know what's good for coding, around, right? Well, I love to do that. And, most of all I can, but I won't. Not now. Just let me take you back 6 years ago, when I was working at Isala hospital. 

Fixing with great effort

I remember doing a fix at the login screen. The user wanted to let the program remember the role which he/she was logging in. Well, if you know me, I fix with great effort. I really don't like confusing classes and many nested business logic. I didn't read the clean code books or watched any video of it at that time, so I didn't know how to convert a class into clean code. Also I didn't know how to write unit tests. In fact, I did heard the words 'clean code' but didn't know what that meant.

First I was trying some things out and after a few hours I knew how to proceed. I locked myself up, set myself apart from the rest and went on. Maybe you know the feeling I felt at that time: feeling a little sneaky, knowing that you are doing something admirable, but in the mean while guilty because you do not involve anyone on purpose while you should have during a growing numbers of decisions.

And all those decisions where crucial points to be tested. I knew at that time that the number of tests or test cases grew exponentially. And still that didn't kept me from stopping my refactoring and certainly I didn't recommend the testers to watch out for more tests in that specific areas. I went on stripping and re-writing the login page and all the classes involved. (There were also classes who had responsibilities and business logic meant for other functionality, so my refactoring affected a whole lot of functionality other than logging in) 

Throughout the years I've been working at Isala, I was constantly remembered as the guy who dared to re-write that crucial part of the program. 

Good job!

Okay, I felt a little bit like being a hero. And that felt good! Or not quite? What the hell did I do? How did I dare to refactor so much code with so many crucial points in the code any many points of no return. I think it took me a whole week and no one actually knew what I was working on. No one asked me questions about what I was doing either. (During the stand up, I said I was working on it and encountered no problems) 

If I look back at that week, I am smiling now, but boy, what did I take a risk! Especially since I didn't created unit tests at all. Furthermore the code itself had no unit tests as well, so I couldn't be sure enough to determine the quality of my work.

Okay, the result was unbelievably good enough. During manual tests no issues were found. But in production one issue was found and it was corrected real quick (not by me). I was hanging by a thread, as a matter of speaking.

Or not a good job?

So, what is the problem then? I was confident enough to proceed with what I was doing. I thought I was doing good, but I was a Pigheaded stubborn developer: looking for trouble! 

1. I didn't let anyone in during refactoring. So no pair programming, so no extra pair eyes looked at what I was doing.
2. After the rigorously refactoring of a week work, I all checked in at once. So no one could really tell what I did and how I did it because of the many changes, so reviewing was impossible. The whole structure of the previous classes was completely gone.
3. I didn't create any unit tests. Unit tests can help you with weighing your classes and their responsibilities. And most of all, if someone changes the functionality, the unit tests will help you on the existing ones.
4. I didn't create end-to-end tests at first, so the functionality and the user experience wasn't being controlled.
5. I pushed it into production and prayed it worked!

So what did I learn? At that time: nothing!

Conclusion

I don't give you a solution and condemn you. You should figure it out for yourself. You should think about the development you did recently and ask yourself: did I comply to these 5 points?

Note: (There are more advantages with tests, but I only focused on these 5 things, just to point out the danger in writing code.)

Take a seat!

Small things

It's in the little things where you don't realize you affect the people who are trying to communicate. In fact, everything you do has affect on your surrounding environment, and even affects a whole lot more, most of the time it's not a big deal, but let's start with being aware with a small example.

Take a seat!

When I'm on the bus, sitting at a two seat and I'm sitting at the windows side, everyone who comes into the bus can take the seat next to me. But, when I'm placing my bag next to me, I create a threshold, a barrier. People do now need to ask me to sit next to me, before they can take their seat. But, if I have my bag beside me and I keep my eyes closed and pretend I'm asleep, I'm creating a small wall around me. People who want to sit next to me are having trouble or difficulties to claim this seat. They first have to wake me and waking someone is not polite. Then they have to ask me to sit next to me.

Back to business.

So, it's in small things you just don't realize what kind of emotional effect you have on people, without being aware of it. Now back to business and ask yourself: what kind of effect do I have on people when they want to ask me a question, or are in need?

You may come with arguments like: when I'm busy, I don't want to be disturbed. I need to finish what I'm doing and then I can answer some questions. You probably don't realize that your reaction can make it harder for someone to ask you a question again. And if you continue to do that, those persons will never ask you any questions anymore. And then you can say: well, it won't come this far with me. I'm nice enough and I'm helping people a lot! Yes, you're probably, hopefully right! And there are some times that you need to be undisturbed. In that case isolate yourself. But at all times: you have to try to take your bag off the seat!