Tag Archives: Unit Test

Continuous Delivery: Unit Tests

This article is part of the Continuous Integration, Delivery and Deployment series.

In the previous article we explored static analysis as one of the first steps in Continuous Delivery. Our journey will continue with unit tests.

Unit Tests

Unit tests are probably the most important part of Continuous Delivery. While unit tests cannot substitute integration and functional tests, they are very easy to write and should be very fast to execute. As any other type of tests, each unit test should be independent of each other. What differentiates unit from other types of tests (integration, functional) is the scope. Each unit test should verify only a single unit of code (method, class, etc). Main benefit of unit tests are that they can find problems early due to their speed of execution. When ease of writing is combined with very short execution time it is no wonder that unit test often represent biggest part of automated tests.
Continue reading →

How can functional test coverage help rescue waterfall projects?

2 Replies

A typical waterfall project has well defined phases that go from the idea conception until putting the solution in production, being the most typical of them:

Requirements gathering
Design of the solution / Architecture
Implementation
Testing phase (including all kinds of tests)
User Acceptance Test
Go Live (put in production)
Post Go-Live support

It’s very common in big companies that there’s a functional team responsible for each phase. Thus, we get:

Business Analysts to gather requirements
Architects, Systems Engineers or Software Analysts to design the solutions
Programmers or coders to implement it
Quality Testers or Quality Assurance engineers to check its quality
The customer to test the delivered solution

However, one of the big problems from this approach is that usually these teams work in silos. The right hand doesn’t know what the left hand is doing and this causes inefficiencies. To make it worse, sometimes the way to try to reduce silos is through an immense increase in bureaucracy, forcing teams to communicate through documentation.
Continue reading →

Learning Python through Katas, TDD and CyberDojo

2 Replies

DISCLAIMER: This is not a tutorial on how to learn Python, in fact, I have never used Python before so don’t take me as example. What I want to share with you is how to learn a new language, strenghen the TDD principles and practice a Kata in an easy way.

Last week I attended the Global day of Code retreat in Barcelona. It was a wonderful experience that generated me a lot of energy to code again (I became a manager some time ago and I don’t code as often as I’d like to). That day we used the Conway’s Game of Life which I recommend to practice the TDD approach.

After investigating about several other katas I stumbled upon the Cyber dojo online tool. Basically this is a web page in which you can practice any kata and choose among more than 20 languages you want to learn without the need to do any setup at all. In other words, if you want to grasp the basics for a new language, this is the perfect place.

Also, one of the nice features from Cyber dojo is that after you’re done with all the coding you wanted to do, you can download all your changes into a zipped Git file and then you have the repository with all the changes that you worked on.

Continue reading →

Test Driven Development (TDD): Best Practices Using Java Examples

22 Replies

In the previous article Test Driven Development (TDD): Example Walkthrough an example of TDD was given. It went from writing first test and its implementation to having a set of requirements fully tested and developed. Now it’s time to learn what the best TDD practices are. This article will be built on examples from the previous one.

Best practices are solutions to a set of problems under certain situations. Not following them would make us “reinvent the wheel” and struggle with the same problems already solved by others. On the other hand, best practices should not be followed blindly. They should be tried out. With an informed decision at hand, they can be adopted as they are, modified to serve better specific situation or fully discarded.

Some of the best practices described here are inherited from other sets of practices and used when doing TDD. For example, most (if not all) unit testing practices should be used when doing TDD.
Continue reading →

Code and Test Coverage

5 Replies

When moving from the traditional waterfall process with manual testing towards BDD with automated execution of scenarios, one of the often asked questions is “how do you measure your test coverage?”. What it really wants to say is “we have high test coverage with manual testing, can you guarantee the same or more with the BDD?”. From there on usually comes the suggestion to transfer one-to-one manual tests to the BDD format. That’s not a good idea since the result would be less than adequate transformation to the different format without any tangible change. BDD is not only about automation but about the way we construct and deliver software.

Code Coverage Analysis

Main usages of code coverage analysis is to:

Find areas of software under test that were not exercised by a set of test cases.
Help in creation of additional test cases to increase the coverage.
Provide quantitative measure of test coverage as indirect measure of quality.
Identify redundant test cases that do not increase coverage
Identify parts of the code that is not in use

Continue reading →

Behavior Driven Development (BDD): Value Through Collaboration (Part 2: Narrative)

Narrative

“User stories are a promise for a conversation” (Ron Jeffries)

A BDD story consists of a narrative and one or more scenarios. A narrative is a short, simple description of a feature told from the perspective of a person or role that requires the new functionality. The intention of the narrative is NOT to provide a complete description of what is to be developed but to provide a basis for communication between all interested parties (business, analysts, developers, testers, etc.) The narrative shifts the focus from writing features to discussing them.

Even though it is usually very short, it tries to answer three basic questions that are often overlooked in traditional requirements. What is the benefit or value that should be produced (In order to)? Who needs it (As a)? And what is a feature or goal (I want to)? With those questions answered, the team can start defining the best solution in collaboration with the stakeholders. The narrative is further defined through scenarios that provide a definition of done, and acceptance criteria that confirm that narrative that was developed fulfills expectations.

Continue reading →