Knowledge Transfer

Ethickfox kb page with all notes

Project maintained by ethickfox Hosted on GitHub Pages — Theme by mattgraham

Backend Testing JUnit Frontend Testing Jest Auto-Testing Cucumber Mocking Mockito

What does a unit test check?

A unit test checks the functionality of the smallest testable elements of an application―classes and functions―which allows developers to spot the failure and isolate it. Unit tests prove that given some input, the function returns the expected output. A collection of unit tests makes up a test suite.

Who is responsible for writing unit tests?

Unlike many other types of testing, unit tests must be written and updated by the same developers who write and adjust the application code. Unit testing is most beneficial for developers because once the test suite runs, they receive autogenerated, rapid feedback on their work.

When should your team write unit tests?

Unit tests must be written at the same time as the main code. This timing makes the code loosely coupled and testable, and it pushes developers to think through edge cases (those that occur only at extreme operating parameters).

When should you execute unit tests?

Unit tests are the first level of software testing and should be executed as early as possible—first, on a local developer workstation once any logically completed piece of code is implemented; second, in the Continuous Integration (CI) pipeline once code is pushed.

How long does it take to run a unit test suite?

It takes seconds to run the whole unit test suite, allowing your team to regularly execute testing without slowing down the development process.

Does a unit test require running the application?

A unit test does NOT require running an application. Your team can perform unit testing easily in an integrated development environment (IDE) or a command line without the need to execute the application as a whole.

Why should you make unit testing a part of the Continuous Integration (CI) pipeline?

As a part of the CI pipeline, unit testing can provide immediate feedback to the whole project team in case an author on your team misses the failure in the local environment.

Unit tests save time by helping your team ensure the existing functionality works even after introducing new features. This is particularly crucial if the application your team is developing for a project is going to be used for several years with more and more features introduced along the way.

When your team integrates unit testing into development at the beginning of a project, you get a more maintainable application in the end. The term maintainable is key here.

Maintainability is the ability to change, understand, and test an application easily. Unit tests contribute to all three aspects of maintainability: they make code easier to change, easier to understand, and easier to test.

Unit Tests vs. Integration Tests

The term integration is often attributed to testing the integration between network services or systems. However, in the context of automated testing, integration describes any connected components. An integration test can verify that internal components of the same application interact properly without any network. This type of test is still an integration test because it assesses multiple entities in combination.


Unit Tests	Integration Tests
Focus on one specific piece of the system in isolation	Focus on the interaction between the units, modules, or components
Are easier to write, faster to execute, and cheaper to maintain	Are more complex, slower to run, and more expensive to maintain
Verify internal consistency of code that you have complete control over	Verify how your code integrates with some other code
Have no external dependency―any external dependency is mocked or stubbed out	Often require interaction with external dependencies, such as databases, network services, hardware, etc.
Let you know the exact piece of code where the error is	Indicate which modules/components contain the error
Are comparable to checking whether a mobile phone battery is alive or whether the SIM card is activated	Are comparable to checking whether a mobile phone battery and SIM card are assembled to start the phone

Principles of Good Unit Testing

Fast - Tests should be fast-running. A whole suite of unit tests should take seconds to run. The faster the tests, the more of them you can have in the suite, and the more often you can run them. When tests run slowly, your team will not run them frequently. As a result, you may not find problems early enough to fix them easily, which limits your ability to clean up the code, resulting in a gradual deterioration of code quality.
Independent - Tests should not be dependent on each other. One test should not set the conditions for the next. Your team members should be able to run each test independently and in any order. When tests depend on each other, the first one to fail causes a cascade of downstream failures, making a diagnosis difficult and hiding downstream defects.
Repeatable - Tests should be repeatable in any environment. If unit tests pass when running one-by-one but fail when running the whole test suite, or if they pass on your development machine but fail on the continuous integration server, there’s a design flaw. Your team should be able to successfully run the tests on the production environment, QA environment, and laptops so there’s never an excuse not to do it.
Self-Validating - Tests should have a Boolean output and either pass or fail. The same test that fails now and passes later is flaky and compromises the whole testing suite. Flaky tests lead to negative consequences. Developers stop trusting tests and start ignoring them, and it becomes challenging to identify non-flaky tests that fail in a sea of flaky tests. You should not have to read through a log file or manually compare two text files to determine if a test passes. If they are not self-validating, then failure becomes subjective, and running tests requires a long manual evaluation.
Timely - Unit tests should be written in a timely manner―before or at the same time as the production code. Testing post facto requires developers on your team to refactor the working code and make additional efforts to have tests fulfilling FIRST principles.

Properly Targeted

A successful test suite targets only the essential parts of the production codebase on a project. For this reason, it is important to differentiate the heart of the application―its domain model―from the rest. Based on the implemented logic, production code is classified into three types.

Practically Unit-Testable

Core functions: business calculations, algorithms, reused (platform) code, etc.

Unit-Testable in Theory

Volatile code: UI controls/styles or unstable prototype (POC) code; changing code will likely result in test failures that are not bugs.
Difficult-to-write unit tests: multi-threaded code, application bootstrapping, autogenerated code, etc.; sometimes unit testing is just not a good fit for verification, and it makes more sense to test on other levels of automated testing (e.g., integration testing).

Intentionally Unit-Untestable

Interactions with external dependencies: network, database, file system, etc.
Boilerplate and trivial code: getter/setter, setup wiring, annotations, etc.

To maximize the efficiency of unit testing, your team should write only the tests whose value exceeds their costs.

Code Coverage Metric

Code coverage is a simple metric often used to locate parts of the codebase that do not have unit tests. Code coverage is calculated as a ratio between the number of code lines executed during the unit test and the total number of lines in the code. In other words, it tells how much code is exercised during the test suite run.

One hundred percent unit test coverage is not enough to guarantee high code quality.