Professional developers test their application but not only with some unit tests and a few acceptance tests. These are components of a testing strategy.

Your company might have a Quality Assurance (QA) department or quality analysts (QAs) in each development team to track bugs before a release. As programmer our role is to let them find nothing, otherwise it means that in a way we failed somewhere during the development phase. Of course this goal is almost impossible to achieve every time but that is not an excuse for letting bugs slip through the code.

Am I saying that the developers and the QAs relationship is adversarial ? Absolutely not, they are parts of the same team. First, QAs are “specifiers”. It means that they are able to translate business requirements into test cases to let the programmers know how the system should behave (more in chapter “Acceptance Testing“). Secondly QAs are “characterizers”. They have the discipline to track incorrect behavior and to reproduce them in order to give proper feedback to development team and to the business.

Having a full test automation policy is a feature of professional development teams which is not only composed by unit tests and acceptance tests. The test automation pyramid figure show every test types and their proportion.

Unit tests are written by the programmers for the programmers to ensure that the code is working at the deepest/lowest level. They should execute in milliseconds and target a 100% code coverage (at least 90%).

Component tests are a part of the acceptance tests and check the behavior of individual component. A component encapsulate a specific set of business rules. These kind of tests should be very quick as well because they are decoupled from the other components and should cover about half the system.

Integration tests are required to check the communication between components in order to verify that the “plumbing” has been done correctly. They ensure that the architectural structure of the system is correct. About 20% of the system is covered by integration tests.

System tests are executed at the highest level of the system, from the UI to check the whole application and its construction (load tests are in this category for instance). They check about 10% of the system.

Manual/exploratory tests are done by humans to explore the application for unexpected behaviors. They need the human creativity to hunt possible hidden bugs.

An effective testing strategy is required to develop reliable applications. This comes from the relationship between QAs and programmers and from a solid automated test suite.

Software craftsman do not only test their code through unit testing they also have to develop an application that meets the requirements defined by the business. Even a well coded, fully tested software can be worthless if it doesn’t have the functionalities wanted by the end users. So, how do you make sure of that ? You do more tests, Acceptance Tests this time ! You write this type of test to validate a User Story. This way you are able to match the functionalities of your application with the desired features. They are formal requirements documents that specify how the system should behave from the business point of view. The audience is the business and the programmers.

For example you might have acceptance tests to check that the login feature is working correctly for each scenario (no input in form, invalid input, correct input etc…).

As acceptance tests are requirements they have to be very specific and written in a language that is understood by the business and by the developers. To do so there are several format to specify the user stories.

“As a <role>, I want <goal/desire> so that <benefit>”

This is a typical user story format. But sometimes it can be too restricted for a proper acceptance test. In that case you can use the Given-When-Then (GWT) pattern especially with the Gherkin language. This Business Readable Domain Specific Language is easy to understand and can be converted to actual tests for the programmers with a tool called Cucumber. If you are working with the Microsoft .NET framework you can use SpecFlow which brings Gherkin and Cucumber into Visual Studio.

Acceptance tests are not unit tests, they allow you to document your software behavior and to match the business requirements. They are proof that the program works technically and functionally.

Professionals practice their art with exercises to improve their skills. A musicians spend endless hours on their instrument between performances, athletes go to training between games. This is what we expect from professionals and we should expect the exact same behavior from software developers. It can happen that your company will give you some time to sharpen you competences and it is a perfect opportunity to learn new technologies. But what if you don’t receive this extra time ? Do you practice at home ? What are the tools that can help you practice ?

You can go to the Dojo ! A Dojo (“place of the way” in Japanese) is a place where you can gather to practice martial arts such as karate, judo, jujitsu, kendo and much more. And there are also coding Dojos where you can practice Katas (“form” in Japanese). These exercises aim to train your mind and muscle your brain by writing a specific snippet of code repeatedly. You can also practice Katas by pair using TDD, Uncle Bob calls these Waza (“Art and technique”), one is writing the tests and the other the code. There are a few online Dojos allowing you to exercise on Katas :

You can also contribute to open sources project, especially now with GitHub. It features thousands of projects waiting for help in every domain you might like and in every programming language you might consider.

But remember that practicing does not mean that you have to work for your employer you can and you should practice on anything you want to do : it should be fun !

I’m sure you have already heard of Test Driven Development or TDD since it has been introduced in the Extreme Programming (XP) methodology in the late 90’s by Kent Beck. This development process relies on a 3 parts cycle : Red – Green – Refactor. You start by writing a unit test that fails (red) because the tested code does not yet exist. After you write the code for your application that makes the test pass (green) and then you can refactor your code to remove code duplication and others code smells.

In “The Clean Coder” Robert Martin defines 3 laws of TDD :

“You are not allowed to write any production code until you have first written a failing unit test.”

“You are not allowed to write more of a unit test than is sufficient to fail – and not compiling is failing.”

“You are not allowed to write more production code that is sufficient to pass the currently failing unit test.”

By following these 3 laws you are locked into a cycle that force you to test every aspect of your code and to fully follow the TDD principles.

Having a full test suite allows you to have the control over the behavior of your application and to avoid any regression after a bug fix or a refactor. The other benefit of having tests is that it provides a detailed documentation for every piece of your program. Each test gives information about the behavior and the expected result of the feature it tests in a given context.

I have to admit that, when writing these lines, I don’t use TDD. Why ? I don’t really have any excuse for not doing it. But I believe in the fact that TDD is a helpful process. I have to practice it in order to absorb it into my everyday development process.

We are developers and by definition we code. For some of us it’s just a job, for others it is a hobby, a craft or even an art ! We spend most of our time coding and by “coding” I don’t only mean writing code I also refer to the thinking of code. This is intellectually challenging and an exhausting activity especially when we are solving difficult problems.

You need concentration and focus to achieve the 4 main goals of coding :

Your code must work !

Your code must solve the problem !

Your code must fit well into the existing system ! This refers to the “do not harm the structure” principle covered in the Professionalismblog entry.

Your code must be readable by other programmers ! For more information you can read another Uncle Bob’s book, “Clean Code“.

You should not work on your code when you are tired or distracted. There is a high probability that you’ll produce waste and you’ll have to redo a huge part of what you’ve already done.

For example you might consider doing a coding night for one of your project. And why not, producing code during all night, especially if you are with some friends looks appealing. But in my own experience it rarely was. I did several coding night with these ideas in mind and it didn’t turn as expected. After 2 am I became completely useless and the code I produced during the night was garbage and the lack of sleep kept me unproductive the day after. Maybe coding nights work for you but it certainly do not for me.

You should also avoid coding when you worry, after an argument for example. Because your mind is not focus on the task you’re working on, it is focus on others issues.

In the book Uncle Bob tell us to avoid “The Zone“. Being in this state makes you feel highly productive, you are focused and you don’t get stuck. So what can be wrong with that ? This is a tunnel-vision state and you lose some of the big picture elements related to your tasks and then you can make decisions that have to be undone later. I must admit that I’m still figuring this out. I would say that “The Zone” is good for algorithmic work and should be avoided for heuristic work (more information here).

In a noisy work environment, the developer best friend is his headphone and his music. But playing music while coding can shift your concentration toward the song you’re listening instead of your code. I think that depends on the type of music you listen, I personally prefer going for pure music (i.e. no lyrics) or you can try some focus music based on brain waves.

When coding the last thing you want is to be interrupted, your thoughts can vanish and you lose all the thinking you were doing. You should avoid distraction, for instance your can close your email software or at least turning notifications off. You won’t miss anything critical, simply because an email cannot be critical. When something is highly important, people will come at you in person. We cannot rely on email for everything, just imagine sending an email when there is a fire. If you don’t want to be interrupted by others persons you first have to explain them why it is important you stay focused, if they don’t understand they probably will not consider it. And remember that sometimes you are the person that are interrupting others.

What if you are rested, your mind is clear, there is no distraction and the code still won’t come ? Well, this is a perfect time to find a pair-programming partner to solve problems with the power of your combined minds !

There will still be times where you will struggle with your task and you will feel like you just cannot resolve it. When this happens you should walk away and come back later, don’t try to force yourself if you are in a non creative state. You might find the solution of your problem the next morning in the shower or after a break.

Coding is our main activity and we have to understand every angles of it and know how to behave as professionals.

The last entry of “The Clean Coder” was about saying “NO“, this time it is about saying “YES”.

This 3 letters word means a lot, especially in a work environment. Why ? Because saying “YES” is a commitment, weare giving our word to someone else. The book gives the 3 parts of making a commitment :

You say you will do it !

You mean it !

You actually do it !

This is what we imply when we say “YES”.

We all know it and this is why we often lack of commitment maybe without noticing it. You can recognize this by the use of the following word : need / should / hope / wish and many more. Here are a few examples :

“We need to get this done” – “We should make this” – “I hope to finish this by the end of the week” – “I wish I had time for that”.

None of these is a commitment and we, at least I, probably said every one of them without doing anything to fulfill the related task/work. It might sounds fierce but I think that without commitments, there is no trust.

Am I saying that we should always say “YES” and commit ourselves ? Not exactly. You should commit yourself only when you have the full control over the task you have to complete. But in the other hand that doesn’t mean that you cannot do anything to complete this task, you might not have the full power but you are not powerless.

“We need to get this done !” So what is the next step we can make to actually do it or at least to participate to its completion ? If you want to learn more on how to do things I can recommand you the book “Getting Things Done” by David Allen.

For example you are waiting for an other team to finish their work in order to finish yours ? What do you do about it ? Do you just wait or do try to help them ? Or maybe you try to abstract their part with a mock in order to continue. There is always something you can do !

A professional doesn’t have the power to say “YES” to everything but he certainly has to power to work toward it.

I know that giving this word as an answer to your co-workers/bosses may sound highly unprofessional but on certain occasions not saying it can have much worst consequences.

Here’s a fictional conversion between a client and a developer to explain the concept.

– Client : “Hey ! We would like to have the feature B for the next release (#5), can you do that ?”

– Developer : “But we agreed to deliver it for the release #7.”

– Client : “I know but this feature will help the business a lot.”

– Developer : “We don’t have time to do all the development and testing for the next release”

– Client : “Look, this is high priority for our customers.”

– Developer : “I’ll try”

– Client : “Thanks !”

What happened here ? The developer just agreed to do extra work he knows he doesn’t have time to do (he said it !). Instead he chose to avoid any conflict by saying “I’ll try” that will bring a lot of confusion in a near future. By answering this the developer says “NO” without saying it and the client understood a “YES”, this will end badly. Maybe it’s possible to meet the deadline by using the “quick & dirty” approach and by removing the tests phase. Doing that is risky for the software and is a violation of the “do not harm” principle, and the way the developer does his profession is dictated by the client.

In this example the developer should have stuck to the “NO” because he “doesn’t have the time to do the development and the tests“. Or he should have tried to switch the new feature with another one to fulfill the client request without adding a new amount of work, it can be a win-win solution .

Professionals are hired to ensure that the direction chosen makes sense and follow the right path. If you don’t behave this way you might just be a laborer.

A few years ago, I was an inexperienced junior developer and I faced a situation like this one. I did the mistake shown in this example and of course when the release came, I was not ready and the situation I had to deal with was far from pleasant.

I’m not saying that you should always say “NO”, this would be also unprofessional, but you need to know when to say it.