Warning !!!

All the knowledge presented below is my notes taken while reading this book, intended for research and study purposes. All copyrights belong to the author Adelina Simion of the book Test-Driven Development in Go

Types of automated tests

Automated testing suites involve tools and frameworks to verify the behavior of software systems. They provide a repeatable way of verifying system requirements. We divide them into several types of tests according to three criteria:

System knowledge: The amount of knowledge they have of the system

Requirement types: The type of requirement they verify

Functional tests: These tests cover the functionality of the system
Non-functional tests: These tests cover aspects such as performance, usability, and security aspects.

The scope of the functionality they cover

Unit tests: Small testing scope, covering the functionality of individual components under a variety of conditions
Integration tests: extend the scope and test the communication between multiple components. These components can be external or internal to the system – a database, an external API, or another microservice in the system.
End-to-end tests: test the entire functionality of the application

TDD

The principle of TDD is simple: write the unit tests for a piece of functionality before implementing it.

TDD best practices

Arrange: set up the Unit Under Test (UUT) and all of the dependencies that it requires during setup., set up the inputs and the preconditions used by the test scenario
Act: perform the actions: invoking a function, an external API, or even a database function. This step uses the preconditions and inputs defined in the Arrange .
Assert: confirm that the UUT behaves according to requirements.

Alternatives to TDD

Waterfall testing: the testing or verification phase of waterfall projects happens after the implementation phase is fully completed.
Behavior-Driven Development (BDD): BDD extends TDD by focusing on the behavior of the application from an end-user perspective. It emphasizes collaboration between developers, QA, and non-technical stakeholders to define the desired behavior of the system.
Acceptance Test-Driven Development: ATDD is similar to BDD but focuses more specifically on defining acceptance criteria for a feature or user story before development begins. It involves stakeholders: product, engineering, and testing in creating acceptance tests that describe the feature’s behavior.

Categorized in:

Tagged in:

, ,