Quick Tech Tips: Relation between TDD & BDD

 Test-Driven Development (TDD) and Behavior-Driven Development (BDD) are both software development methodologies focused on ensuring quality and correctness, but they have some key differences and relationships:

TDD (Test-Driven Development)

• Focus: TDD focuses on writing tests before writing the actual code.

• Process:

  1. Write a Test: Write a test for a new feature or functionality.

  2. Run the Test: Run the test and see it fail (since the feature/functionality doesn’t exist yet).

  3. Write Code: Write the minimum amount of code required to make the test pass.

  4. Refactor: Refactor the code for optimization and maintainability.

  5. Repeat: Repeat the process for new features or improvements.

• Tests: TDD typically involves writing unit tests that test individual components of the software.

BDD (Behavior-Driven Development)

• Focus: BDD extends TDD by focusing on the behavior of the application from the user’s perspective. It emphasizes collaboration between developers, testers, and non-technical stakeholders.

• Process:

  1. Define Behavior: Define the desired behavior of the application using plain language (Gherkin) in the form of features and scenarios.

  2. Write Tests: Translate the defined behavior into executable tests (often automated).

  3. Develop Code: Write the code to make the tests pass.

  4. Refactor: Refactor the code for optimization and maintainability.

  5. Repeat: Repeat the process for new behaviors or improvements.

• Tests: BDD involves writing acceptance tests that describe how the application should behave in various scenarios.

Relationship between TDD and BDD

• Complementary: BDD can be seen as an evolution or extension of TDD. While TDD focuses on the technical aspects and internal correctness of the code, BDD emphasizes collaboration and understanding the business value and user behavior.

• Layered Approach: In a BDD practice, TDD is often used to write unit tests for individual components, while BDD is used to define and verify the overall behavior of the system through acceptance tests.

• Common Goal: Both methodologies aim to produce high-quality, reliable software by ensuring that code is thoroughly tested and meets the requirements.

In summary, while TDD and BDD have different focuses and processes, they can be used together to achieve a comprehensive approach to software development and testing. By combining the strengths of both methodologies, teams can ensure that the software is both technically sound and aligned with user expectations.

Shift from Manual to Automation - Unit Testing

 This post is about the shift from manually unit testing your code to enabling automated tests using Assertion Frameworks. This post is intended for audience who are completely new to the discipline of software unit testing.

Let's take a simple example of a Guest Entry system, where 

1. When a valid guest enters, your system (here shown as the watchman) validates the guest pass (login credentials), and let's the guest enter as an authenticated user
2. When an intruder (not a system user) enters, your system should be able to know that the user is invalid and NOT let him enter your system any further

If you are a manual tester or unit tester testing this module / functions of module, then you would want to record it in an excel file like this.

The above steps would keep repeating for each test case, right?

When you wear the hat of a tester, there are 3 things which you need to know

• Example inputs. This is usually given by clients in a call.
• Expected outputs. For each input, the expected output should be known
• The function to call

Hence, in the case of Guest Entry, let's take the example inputs, expected outputs, function to call

• Example inputs: [userId | password] = ["admin" | "nimda"]
• Expected output : returns "Valid Guest"
• Function to Call: GuestLogin(userId, password)

To automate this test case which is already represented in above diagram as excel sheet, we make use of Test Assertion Frameworks

1. The Test Assertion Frameworks take Example Inputs, Expected Outputs, Function to call AND compare them with the actual output returned by the function call.
2. If the comparison returns true, the test assertion framework declares that the test case has passed.

Irrespective of the assertion framework used, we use the AAA pattern which works with any assertion framework available today

A - Arrange

A - Act

A - Assert

Here is an example of a test case written for testing the function "Add()" using AAA pattern

The above testcase is written using NUnit in .Net. One could choose to use any framework to write the testcases. 

There are several Assertion Frameworks available today. Adding some of them for your perusal here.

To be able to be a unit tester, one needs to have the mindset to think like a tester. To think like a tester, one should know only the following things

• Example inputs. This is usually given by clients in a call.
• Expected outputs. For each input, the expected output should be known
• The function to call

Now use the assertion framework of your choice and write testcases for your code.