Shedding Light on the Differences Between Test, Unit Testing, BDD, TDD and Acceptance Testing

Introduction

There are many myths about *test-ish in software development. What is the essence of software testing? What is the purpose of a “unit testing”-kind of software testing? Should we consider this a “unit test” or an “integration test”? Why do we really need someone to replace the “T” in “TDD” with a “B” and then start a philosophical conversation about the differences between the “T” and a new “B”? Is the Acceptance Test just yet another replacement or alternative for “BDD”? In the following, I’m gonna(okay, okay going to 😊)show you my thoughts about those kinds of questions in an unorthodox way of thinking. So, let’s start with ….

Of course, “Test” and “Testing” in general.

It’s all about “Test” and “Testing”

Yes, all the debates are about testing the software, whether before or after testing, or even manual testing or automated testing. According to Oxford Language Dictionary tests can be a noun or a verb:

As a noun it means:

a procedure intended to establish the quality, performance, or reliability of something, especially before it is taken into widespread use.

As a verb:

take measures to check the quality, performance, or reliability of (something), especially before putting it into widespread use or practice.

So, in short, think of a test as an explicit, concrete, clear, outcome focused, business-wise (at least code-wise 😉) step-by-step procedure created due to the proof-of-work of something. Testing means run those tests or use those tests in order to accept or reject something about something. Ok confusing. Let’s run an example.

Let’s say we are going to craft a tea mug. As a tea mug for pouring tea in it, it should have a handle that is resistant to hot water to prevent hand burns.

So, the procedure of test would be something like this:

• Boil some water to 100 ‘c
• Pot a tea-bag in the tea mug
• Pour down the water
• Be cautious🙂
• Touch the handle
• Wait for 20 seconds
• Look at your fingers
• They should not be hot

As you can see, the procedure consists of a list of steps, followed by each other, focused on just one thing, concrete and also it’s measurable, quantifiable and quantifiable. It’s very crucial for a test procedure.

Testing means going through those steps, and at the end, accept or reject the tea mug under test.

Look at the test again. The test is focused on just one aspect, one property of the tea mug under test. It’s not the proof-of-work of a tea mug as a whole. I mean passing the test doesn’t mean that the tea mug is totally accepted. Passing the test just says that the tea mug is resistant against the hot water or hot tea. It acts as the proof-of-work of one unit of the expected final product. We need other tests for other units-aspects of expected tea mug products.

Unit Testing

So far we understand the meaning and purpose of a test and the act of testing something. Now we can imagine how important tests(or test cases) would be. I want to emphasize one more time on the “proof-of-work” part of tests.

As the name goes unit testing is all about a unit of something. We replace something with the word “work”. So let’s revise the definition one more time. Unit testing in a nutshell means testing a unit of work.

What does it mean by unit? Unit here means an individual part of a system regarded as single and complete and isolated. Nothing here is about size. Unit can be in any size, or any layer. Being complete and single is more important than size.

What does the word “work” refer to? “Work” means that individual parts should be business-wise.

So, unit test means testing an individual part of a product regarded as single and complete.

Examples:

• Testing “placing or order”
• Testing “canceling or order”
• Testing “booking an economy flight seat”
• Testing “Changing the active address of user”
• Testing “Defining new subledger account”
• Testing “Sending email-notification after placing or order”
• Testing “adding items to a cart”
• Testing “generating purchase orders”
• Testing “updating product inventory”
• Testing “checking product availability”
• Testing “handling out-of-stock situation”
• Testing “processing return of product”
• Testing “generating purchase order”

Test-Driven Development (TDD)

The first thing that comes to mind when we hear TDD is a cyclical approach known as Red => Green => Refactor.

TDD is a philosophical approach in developing software in an evolutionary manner in a step by step(actually tiny steps) guided by tests. We know what we want to write in code. We write a test as a documentation of what is inside our mind about what we’re going to write. The test will fail of course(Red phase). Because there is not any code yet. Then we write just enough code to pass the test(Green phase). And finally we refactor the code to make it right(Refactor).

The main point of TDD is not tests. It guides the software through a sequence of tiny-baby steps in an emerging, evolutionary manner. Every step is based on the design that is the artifact of previews steps. Here in TDD the main driver of our design is TESTS. Driver of everything should come before them. So it’s the case for the Test part of TDD. If tests are the main driver of our design, if our design is in (production)code, and if the driver should come before the design THEN tests should come before (production)code. Confusing 🙁? Read the paragraph again. Got it ;)

TDD’s Limitations and the Rise of BDD

TDD has some potential limitations and is prone to misuse and misunderstanding. Test as the main driver of design, is too technical. It’s not an appropriate tool to get people together. Business people can not make connections with tests. One potential issue with TDD is that some people find it counterintuitive to test something before it exists. In the real world, we typically test things that have already been built. However, TDD involves writing tests for functionality that doesn’t yet exist, which can be a new concept for some.

To address these challenges, Dan North developed a more collaborative approach to system specification called Behavior-Driven Design (BDD). BDD focuses on defining desired behaviors and outcomes, using examples to illustrate how the system should work. This approach emphasizes communication and collaboration among stakeholders.

By focusing on behaviors rather than technical implementations, BDD aims to bridge the gap between business requirements and technical development, ensuring that the software meets the needs of its users.

BDD typically involves the following phases:

1. Discovery: This phase involves gathering information about the system’s requirements, goals, and constraints. Stakeholders, developers, and testers collaborate to identify the desired behaviors and outcomes.
2. Formulation: The discovered information is used to create clear and concise examples that describe the desired behaviors. These examples are often written in a Given-When-Then format.
3. Automation: The examples are automated into executable tests. This helps to ensure that the system continues to meet the defined behaviors as it evolves.
4. Execution: The automated tests are executed regularly to verify the system’s behavior.
5. Feedback: The results of the tests are analyzed and used to provide feedback to the development team. This feedback can be used to identify areas for improvement and make necessary changes to the system.

These phases are iterative, meaning they can be repeated as needed throughout the development process to ensure that the system continues to meet the defined behaviors.

BDD Example: An Online Shopping Cart

Imagine you’re building an online shopping cart. Using BDD, you would start by collaborating with stakeholders to understand the desired behavior of the cart. You might identify key scenarios such as adding products, removing products, calculating the total price, and proceeding to checkout.

Next, you would write examples to describe these scenarios in detail. For instance, you might specify that when a user adds a product to their cart, the product should appear in the cart summary. Or, when a user removes a product, it should be removed from the cart.

Examples of BDD Scenarios for an Online Shopping Cart

Scenario 1: Adding a Product to the Cart

• Given: A user is logged in and browsing products.
• When: The user clicks the “Add to Cart” button for a product.
• Then: The product should be added to the user’s cart, and the cart total should be updated accordingly.

Scenario 2: Removing a Product from the Cart

• Given: A user has a product in their cart.
• When: The user clicks the “Remove” button next to the product.
• Then: The product should be removed from the cart, and the cart total should be updated accordingly.

Scenario 3: Calculating the Total Price

• Given: A user has multiple products in their cart.
• When: The user proceeds to checkout.
• Then: The total price of all products in the cart should be calculated and displayed correctly, including any applicable taxes or discounts.

Acceptance Testing

Acceptance Testing is a type of testing that ensures software meets the specified requirement at a high level. Acceptance Tests are written from the end-users point of view. It views systems in a black-box that give an input as a decision, process them and expect to have an observable effect based on the decision.

Let’s say a user decided to buy a book on Amazon. They make their decision by adding a book to a basket. After that they expected to have a basket with one book on it. So, in this scenario to check that the system is met this requirement we write a test as follows:

• If
• The user’s basket is empty
• The user select a book
• When
• The user add it to the basket
• Then
• The basket has the book on it and ready to paid

Acceptance testing is sometimes confused with BDD. As said before BDD is more than testing. It’s an agile practice. In the automation phase of BDD we write acceptance testing. Actually we automate some of the scenario and examples, revealed as the artifacts of exploration.