Brings a test over a fundamental unit of code, usually functions or classes. It’s highly attached to how the code was written.

Get a function or method.

Insert inputs and call it.

Compare the response.

Review code quality.

Tests how users use our software and not our internal implementation as unit tests. Includes all relevant components that involve certain user behavior.

Builds a virtual representation of a UI element.

Simulate a user interaction over the element: clicks, scroll, mouse over, etc.

Compares the behavior with the expected result.

Meet user stories, 1 user story ~ 1 functional testing.

Evaluate the UI according to the expected design, works over the user interface looking at what happens when clicking a button or scrolling a page, etc.

Builds a virtual representation of a UI element.

Simulate a user interaction over the element: clicks, scroll, mouse over, etc

Compare the response visually with the original design.

Sync UI developers and designers.

Focused on checking data communication between modules of code, and API communication.

Get an API.

Call it.

Check structure and content.

Validates the data structure and its content from our APIs.

It's performed by users after testing the system and before making it available for actual use on market.

People outside the developer team use the app in production.

Gather real metrics.

Compare it with business metrics.

Validates if business requirements are met.

Internal Acceptance (or Alpha) Testing is performed by members of the organization that developed the software but who are not directly involved in the project.

Customer Acceptance Testing: performed by the customer of the organization that developed the software.

User Acceptance (or Beta) Testing is performed by the end-users of the software.

As we saw, testing doesn’t require code implementation to be done, TDD is the practice of writing our tests at first and later writing the code.

Steps:

Write “shell” component or feature.

Write the tests and import your shell component into them.

Fail the tests.

Write code until it passes the tests.

Testing neglect is avoided and requirements are enforced by ensuring that your code conforms to testing and not vice versa, and also helps to write better code from the beginning making us think in requirements before we write a single line of code.

So far, doing automatic testing sounds like the best solution, and it is, but a bad implementation can turn it into a nightmare. I trust that by having clear concepts, following the next suggestions, and practicing a little (with the tool you want), you will avoid the most common mistakes.

Run tests in isolation between other tests and other components. One file per component, one or more tests per feature, and one test for one requirement.

Test edge cases and error paths not just happy ones, because we want our tests to cover a wide range of scenarios.

Establish a domain and range (inputs & outputs) for each feature we are testing, in this way, when a certain input is received we can be sure of the type of result that we can expect.

Apply SOLID principles to write, clean, modular, and descriptive software, avoiding:

Swamp of global variables.

Pointer soup.

Side effects (as possible).