If you researching Agile or methods to improve your testing or code delivery, no doubt you’ve heard of Test-Driven development (TDD). But why are so many people talking about TDD these days? Let's explore this and answer your specific question regarding the benefits.

What are the benefits of Test-Driven development? Fewer defects, speed of delivery, more cost effective, easier to test and more efficient code.

The reality is there are many benefits for TDD. Whilst these are the main benefits, it Is important to see why these are benefits and understand how this can benefit your business or career as a tester.

What is Test-driven development (TDD)?

TDD is developer centric method of preparing unit test cases ahead of development or design. The unit test cases effectively form the design of the code created.

This is different to traditional techniques such as the [waterfall method] or [V-Model]. This is because in these models the design is done up front, and test cases and code are driven by this design.

In TDD, the unit test cases will become the design for the code.

What are the pros and cons of TDD?

To truly answer this question, we need to break this down into a few sub-headings or bullets, because the list is quite extensive.

Pros:

• Speed of delivery
• Fewer defects
• Efficient code
• Easier to test

Cons:

• Slows down development
• Requires highly skilled testers
• Hard to apply to existing development projects

Here is a breakdown of these Pros:

Speed of delivery: Once you have the tests laid out, the coding is easier to complete. This is a two-edged sword, as you will see later, because this can also be seen as a gift and a curse.

Fewer Defects: Because the tests are created up front, it is easier to test and eliminate potential defects. This is because the test team will think of the potential errors up front to tests, allowing the dev team an opportunity to cater for these issues up front.

Obviously, you will still find defects, but, if done correctly, it should greatly reduce them.

Efficient Code: Because you are focused on specific test cases, you will have more efficient modular code. Rather than thinking about the application as a whole, you can focus on that more focused modular code.

Easier to Test: Because the test cases are created up fron and form the design, you have a clear plan of tests before the application is created. It means that the testing process should be straight forward.

All the test conditions should be in place and ready to go as soon as the code base is available.

Here is a breakdown of these Cons:

Slows down development: This was the “Gift & Curse” that I mentioned earlier. From a project perspective the TDD method will help efficiency and speed. However, the actual development phase cannot start until the test are laid out.

It is still beneficial doing it this way, but just understand that there is a hit on your development start date using this method.

Require Highly skilled unit Testers: Because the testing is the center of this method, it is actually the tests that have to be high quality. What does this mean? Well, for example, you need to consider every potential test condition, before development.

A novice unit tester with little experience may be inclined to create a list of “happy path” tests, that may skim over many potential issues that the code can introduce.

Therefore an experienced unit tester with not only theory of the method, but experience of working in similar projects and understanding of the actual software that is being created.

For example, if you are building a new CRM system for the energy market. You will not only need a skilled TDD unit tester/developer, but one that has knowledge of the energy market to understand the service requests, market messages, etc. Are you with me?

Harder to apply to existing projects: If you have an existing, legacy system. The chances are you have processes in place already to test and develop it.

It is quite hard to transition from an older method, such as the [v-model] for example, to TDD. Not only will you need to change your processes, you will need to re-skill your staff, or bring in new staff to cover this. All of which will incur challenges and cost.  

What are the stages of Test-Driven development?

There are three key stages to TDD: Red, Green and Refactor. Each stage is as follows:

Red Phase: This is where the tests are created ahead of development, and arguably one of the most important stages in the process. If you miss something here, you will have a tough time getting the project to be successful.

Green Phase: This is where the code is written to address the tests created in the red phase. This is an ultra-focused process because the heavy lifting should have been done in the first stage.

Refactor Phase: This is the stage to tidy up the code. Such as making sure it is readable and maintainable. The green phase really focussed on making sure the code covered the test cases, which effectively have become the requirements.

Related Questions and Answers:

How is TDD different to ATDD and BDD? TDD, as discussed is focussed on creating tests up front. BDD or “Behaviour Driven Development” is, as the name suggests, a behaviour related methodology. It focuses on “Is this really what we should be testing?” as a continual question.

The BDD method makes sure that user stories that are built reflect actual business functionality. Whereas TDD is focussed at a unit test level, largely focused on code.

ATDD stands for Acceptance Test-Driven Development, it is highly collaborative methodology that encourages interaction from developers, users and testers. An acceptance test is created, from a users perspective and the code has to deliver based on this acceptance criteria.

The biggest difference between TDD and these methodologies is the stakeholders involved. TDD is largely a developer driven methodology without the interaction with other stakeholders.

How is TDD different to the traditional development process? With the traditional development process, the coding is done up front based on some ridged requirements, usually compiled by a Business Analyst (BA).

In parallel the test team would typically write test cases, to test that the code matches the business requirements. With the developers writing unit tests after the code is complete, to check that the code is fit for purpose and ready for the system test team to start their test phase.

With TDD however, this is flipped on its head. With the developers writing their unit tests up front, then coding. Once the code is done, it will be “Tested” to see if fails the pre-written test. Nowadays these are typically automated tests.

So there is a distinct difference here.

Is TDD Good for you? The decision to use TDD is quite subjective. As discussed it can help to make more efficient code, cut costs and focussed development iterations. Another benefit that has not been addressed earlier is the fast feedback to the developer to improve their code and help for a better quality release.

Benefits of TDD to software Testers

As a tester, TDD can help because each code unit will have a documented use case. Making it a lot easier to design and plan a suite of tests. With Agile testing it can sometimes be difficult to test, when you are asked “Test This”, only to discover that their os no documentation and your project manager presents you to a “moody” developer to get the “requirements”.

This method will help to give you some documented conditions and push back if you are challenged on how this test passed, etc. All in all it will benefit everyone on that basis.

Simply put, a user story is the smallest unit of work in the agile framework that serves as a software system requirement.

Here is an in depth look into User stories and Agile characteristics:

What is an Initial User Story

Initial user stories are much smaller and basically define the interaction between the end user and the system in certain usages and scenarios.

Two types of Initial User stories exist: Formal and Informal.

1. Formal User Stories:
   These are detailed sentences that help programmers identify the actors (team leaders, members and product owners) and their business value as a requirement
   
   A formal approach is usually applied with the template:
   e.g. As a (role) I want (something) so that (benefit).
   
   For example: As a reporter, I want a transport allowances so that I can travel and cover stories.
2. Informal User Stories: -These are usually high level stories with no specified format in the actual story card. Their simplicity with no rules makes them easily distinguishable from other Agile stories.

What is an Epic?

Looking at the bigger picture after writing your user story lies an epic. This is a much broader chunk of work with a common objective.

A product owner can write a user story that seems really simple at first and puts it under a single sprint. In real sense, it becomes impossible to finish it in time and is then carried forward as an Iteration backlog.

The big user story now an epic, needs to be split into smaller user stories to obtain a better estimate of the sprint

Both the epic and user stories are used to classify the amount of work to be done. Epics differ from each organization.

Giant tech companies have bigger epics as compared to smaller companies whose epics could probably be done within a single sprint.

It’s also important to mention features under agile methodology. Features refer to the strategy layer that user stories try to accomplish.

An epic comprises of several features within which also comprise of a couple of user stories.

What is a Theme?

As a product owner, you may choose to diversify and change to other aspects to maximize on profits. A theme a large area of focus usually assigned to different teams.

A theme may or may not include epics of related proportions. The user stories in a particular team may be totally unrelated thus spanning the organization.

In the same way epics are made of different user stories, a theme is made of different epics. It is important to also mention Initiatives. 

Just like features, initiatives lay the foundation of epics driving them towards a common goal.Initiatives take much longer to complete than epics. Initiatives have structural designs that clearly define the epics and their time frames.

One major characteristic of a theme is that its overly ambitious. It mostly defines the product owners’ dreams and goals in partnership with the stakeholders. They sometimes inspire the teams to create reasonable epics in regression to the original Agile idea.

The themes are used to organize the epics for better processing.

What is a User Persona?

To fully understand what a user persona is, a background check into the world of marketing is in order. Remember a developer cannot create a program without actually knowing about the consumer base and their needs.

In software development, there is a team responsible for researching related topics on the project and give feedback to their teams. This data obtained which usually contains a list of pros, cons, goals and complications are arranged in a manner that reflects a data persona.

A user persona is that a character that is a representation of a user who will interact with the product you are passing. It may be a program, an app or another software entirely designed to target how best your product will perform in the market. 

If your product is a web-based feature, it is expected that it will receive more than one user. Therefore, it is advisable to create more than one use persona to adapt with the increasing number of traffic inside your website.

As mentioned above, a user persona’s initial stages of development usually comprise of market research. These include the use of prototypes that are released to beta testers who have already subscribed into testing of the persona. 

The beta testers give out their general feedback of the working of the program on interviews or focus groups where they share their opinion. Areas of improvements are shared and worked on in the tasks to come.

What is an Acceptance Criteria?

According to leadingagile, they are a group of conditions that need to be met to satisfy and accepted by a user or customer.

They are one of the most important things to get right, from the start, so you know when you have done enough testing to exit the process.

Final Words on User Stories

The incorporation of user stories into software development has made the task more human friendly as opposed to other impersonal methods. Its launching is more thrilling as it contains actual conversations of the user requirements that a client demands.

As part of the team, you may need to complete a user story diligently and fast since anyone in management including the stakeholders can write a user story and add to your collection.

If not properly handled, user stories can pile up to form company backlogs which are enemies of progress.

Before you go, lets delve into another buzz word in Agile, ATDD...

Really? Is this What ATDD in Agile Stands for? The inside scoop!

What is ATDD?

One framework that has been gradually rising is ATTD, which stands for Acceptance Test Driven Development.

What is ATDD?

​
ATTD is an Agile based developmental framework that involves communication between the business stakeholders, customers, developers and down to the beta testers. 

At the same time, the user stories once executed are passed through several detailed acceptance tests that check on how the system will perform as per the user’s point of view.

The difference between this tool and Scrum is that the latter’s User story is scrutinized by the developer and the product owner and run against several Acceptance criteria to check on its overall functionality. In other words, the tests are done immediately the user stories are written prior to any development work.

Is it also referred to as Story Test Driven Development (STDD)?

In order to clearly define what an STDD is, it is fundamental to learn about the Test-Driven Development (TDD). This methodology involves a short development cycle that is usually repeated until it passes the required test criteria.

It can be very tiresome since the first test is usually targeted to fail and with the subsequent tests geared towards software improvements.

The Story Test Driven Development is subset of the TDD that focuses on higher level acceptance tests. So, in a way the collaborative framework is also sometimes referred to as a STDD though less commonly.

The STTD comprises of four major key components namely:

1. System specifics: - Written in HTML the document briefly describes how the software is expected to function.
2. Acceptance Test Fixture: - This reads the system specifics Html to ascertain that the specifications are adhered to
3. Unit Test cases: - As the name suggests, these are tests specifically run as a unit to make sure the software runs as intended.
4. Story test results: - With all said and done, a summary of all the acceptance tests and their results are recorded here.

What about Behaviour Driven Development (BDD), is it the same?

According to gaboesquivel, BDD is a subset of the TDD. It is totally different from the collaborative framework in that its software operates on principles like, designing and programming a unit test and ensure they fail before finally implementing and verifying the implementation of the unit.

BDD generally gives a consistent customer-based reception allowing for the inclusion of everybody involved in the process whether they are conversant with developer options or not.

What this means is that as a customer, your needs will be put first before anyone else. Another difference of the BDD is that it focusses on how the system operates whereas the framework in discussion drives at carefully meeting the acceptance tests needed for efficient software functionality.

The tool structures that support the BDD include the JBehave and RBehave developed by Dan North. In these structures, the framework specifies and executes the tests for each scenario bearing in mind the schematics of the scenario.

What are the benefits of ATDD?

The long chain of activities involved in this framework finally pay off in the following ways.

• Quick solutions to problems arising: - the world of designing and developing software is challenging and filled with setbacks. As such, it requires a tool that can instantly solve some of these problems. It accomplishes these problems by sharing the design and testing it in its early stages
• Simpler to Manage: - Unlike TDD, this framework is known to incorporate everyone into it meaning, smaller user stories will be assigned to each team to be completed during a shorter timeframe. Smaller builds are usually easier to monitor and manage especially in distribution of resources.
• Customer focused: - this design puts the needs and preferences of the customer above all else. Through prior research within the market, developers have it easier to do their work especially with the needs of the consumers in mind.
• Bridges the gap between different teams: - According to qasymphony, it improves the efficiency in the development process. It's collaborative efforts initiate communication between the developers and the stakeholders alike thereby closing the gap.

What are the common Pitfalls?

Like every other software framework, the ATDD isn’t lacking in a few cons:

• This method is geared towards the customer’s satisfaction which can be a a huge blow to the product owner especially if their interests don’t align.
• The framework is designed to operate under specific tools like Cucumber that requires mastery and constant practice. As such, this will deter the primary objective of the framework to improve on the collaborative interaction between the stakeholders and developers.
  
  

Final Words on ATDD

ATTD is becoming more popular for simple reasons like anyone being able to write and run the acceptance tests. In the ever-digital competitive world, it offers more dynamic and efficient improvements to your product throughout its automation features.

If you can use a method that will get you faster results, why not take the chance?