Unit Testing Concept
Let’s remember the Unit Testing concept in the first place.
Roy Osherove has elaborated a definition that says: “A unit test is an automated piece of code that invokes a unit of work in the system and then checks a single assumption about the behavior of that unit of work.”
As it stands out from the definition, “a unit test is an automated piece of code.” So a unit test is not more than a program that runs testing your program.
Moving on along the definition, we find that the “piece of code invokes a unit of work”, this clearly means that no human intervention is needed here. Continuing with the definition it says that “checks the single assumption about the behavior”.
Again, this means that the test script code acts alone without human intervention for checking the results.
Consider the fact that a “unit” is just the smallest testable piece of code.
Shortly we can get the following from the definition:
- A Unit test invokes some piece of code
- It compares the result of of the tested code with an expected result
- All the processing is done with the minimum human intervention
So the developers write their unit tests just for making sure that everything does what it was supposed to.
In this way developers write their code and then they write the unit tests but, What if these steps are inverted?
We are talking about writing the tests in the first place and later writing the code that makes those tests to achieve the expected results.
This technique leads us to:
TDD: Test Driven Development
Test Driven Development is a method of programming implemented from the developer's point of view. It starts with the QA Engineer writing test cases for every single app feature. This practice tries to get the answer to the question: “Is the code valid?”
The goal of this technique is to produce new code or update it only when a test fails and as a result it ends minimizing the number of duplicated test scripts.
This method is widely used in agile software development environments.
In TDD the automated test scripts are written just before the code to be tested itself by following this steps:
1. Based on the documentation, the developer writes a test case for each requirement.
2. Then those test cases are executed. At this point the test cases will fail because the testing subject is not developed yet. If tests pass, that means that those functions were already developed in the project and a research is needed on how they can be reused.
3. Write the feature’s code
4. Test the new code by running again the tests written at step 1. If they pass, the requirements are met and the development is completed.
5. Then refactor. Do not forget to optimize the code following the best practices.
6. Repeat the steps if needed until the whole development is done and the test are successful.
As it is clear this technique gets the development done with the test execution result in mind so the chance to get an error is lowered drastically.
Some of the benefits of implementing this methodology are:
- In TDD the required rework time is reduced
- Bugs and errors can be found really fast
- Feedback is fast too
- TDD helps to get tidier designs
- TDD raises the development productivity
- By collaborating with each other, everyone can start developing the code without falling in the need of the code owner being present
- Makes the big architectural changes easier
- TDD produces an easy to maintain code
BDD: Behavior Driven Development (or how the feature behaves)
By defining the features reach and the requirements several players got involved other than only developers. It is common to get the requirements done by a Product Manager or even other business experts. So due to the team members interaction could be a good idea to develop the features behavior together.
There are some languages that were specifically designed to do this like Gherkin.
Gherkin language follows a specific syntax that consists of Given-When-Then to show what should happen or how the application should behave. This produces a really easy to understand set of specifications.
A great advantage of this approach is for developers. They do not need to write new test scripts each time the code is modified. This is due to the fact that BDD is not focused on the code itself but on the application behavior.
Here are some of the BDD advantages:
- Every team member can understand the test cases because they are not written in a programming language.
- Business experts can ensure that the application behavior was correctly transmitted
- Requirement discussion and team collaboration becomes easier and everyone can work actively in a common goal.
Regarding the fact of including business experts to be involved in the development process, we can ask the following question:
What if the user or client gets involved in the process?
Here is where ATDD enters the scene.
ATDD: Acceptance Test Driven Development
The ATDD is a technique where an acceptance test is written from the user or client’s perspective.
By focusing on satisfying the functional behavior of the application, ATDD tries to answer the question: “Is the code working as expected?”
At first glance BDD and ATDD are similar, but there is a difference between them. While BDD is focused on the feature’s behavior, ATDD is focused on accurately capturing the features requirements.
Some of the main ATDD principles are:
- Work with real world scenarios and cases
- Accurately define those cases acceptance criteria
- Automate the cases
ATDD brings a higher collaboration among cross team members. As the requirements are clearly defined using several different points of view, they are correctly defined and also the acceptance test acts as a guide for the whole development process.
Several techniques and methodologies but.. Which one is the best?
As you already know, for achieving a strong and high quality product a multi level testing is needed. So as TDD needs unit tests and ATDD works with acceptance tests when those methodologies are combined a low level and high level application test is performed.
So, as ATDD and BDD are very close and the BDD’s star characteristic is the information around the the application’s requirements and as ATDD is closer to development than BDD is (so as TDD), to achieve the goal of getting an improved and heavily tested application that brings a strong quality to the user, the three main actors should be in the same page: Business, Development and Testing.
As A Conclusion
If the company can combine these techniques together, test scripts would not be written as a small part of the development but with a really wider scope and coverage by getting more actors actively involved in the process.
Then the result is that the application will satisfy the requirements and development cycle will become more efficient.
The code will also carry fewer errors and all this allows the QA team to focus and move forward to more complex test cases.
If you require aditional help with software testing and QA for your product or application, feel free to reach Devlane.
Thanks for reading!
