What is the difference between Unit, Integration, Regression and Acceptance Testing?

Question

Is there anyone that can clearly define these levels of testing as I find it difficult to differentiate when doing TDD or unit testing. Please if anyone can elaborate how, when to implement these?

Answer 1

The answers above are good anecdotal ones. Here are some definitions from canonical sources, i.e. ISO, IEC, and IEEE Standards.

---

Software and Systems Engineering Vocabulary

Unit

unit test. (1) testing of individual routines and modules by the developer or an independent tester (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) test of individual programs or modules in order to ensure that there are no analysis or programming errors (ISO/IEC 2382:2015 Information technology -- Vocabulary) (3) test of individual hardware or software units or groups of related units (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)

Integration

integration test. (1) progressive linking and testing of programs or modules in order to ensure their proper functioning in the complete system (ISO/IEC 2382:2015 Information technology -- Vocabulary) See Also: integration testing

integration testing. (1) testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)

Regression

regression test. (1) retesting to detect faults introduced by modification (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)

regression testing. (1) testing performed following modifications to a test item or to its operational environment, to identify whether failures in unmodified parts of the test item occur (ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.64) Note: Regression testing differs from retesting (3.15) in that it does not test that the modification works correctly, but that other parts of the system have not been accidentally affected by the change.

Acceptance

acceptance test. (1) test of a system or functional unit usually performed by the purchaser on his premises after installation with the participation of the vendor to ensure that the contractual requirements are met (ISO/IEC 2382:2015 Information technology -- Vocabulary) See Also: acceptance testing, validation test

acceptance testing. (1) testing conducted to determine whether a system satisfies its acceptance criteria and to enable the customer to determine whether to accept the system (ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary) (2) formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a system or component (IEEE 1012-2016 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1) See Also: acceptance test, validation test

Copyright©, 2024, IEEE. Used by permission.

Answer 2

Can't comment (reputation to low :-| ) so...

@Andrejs makes a good point around differences between environments associated with each type of testing.

Unit tests are run typically on developers machine (and possibly during CI build) with mocked out dependencies to other resources/systems.

Integration tests by definition have to have (some degree) of availability of dependencies; the other resources and systems being called so the environment is more representative. Data for testing may be mocked or a small obfuscated subset of real production data.

UAT/Acceptance testing has to represent the real world experience to the QA and business teams accepting the software. So needs full integration and realistic data volumes and full masked/obfuscated data sets to deliver realistic performance and end user experience.

Other "ilities" are also likely to need the environment to be as close as possible to reality to simulate the production experience e.g. performance testing, security, ...

Answer 3

Unit Test: is my single method working correctly? (NO dependencies, or dependencies mocked)

Integration Test: are my two separately developed modules working corectly when put together?

Regression Test: Did I break anything by changing/writing new code? (running unit/integration tests with every commit is technically (automated) regression testing). More often used in context of QA - manual or automated.

Acceptance Test: testing done by client, that he "accepts" the delivered SW

Answer 4

Unit test: when it fails, it tells you what piece of your code needs to be fixed.

Integration test: when it fails, it tells you that the pieces of your application are not working together as expected.

Acceptance test: when it fails, it tells you that the application is not doing what the customer expects it to do.

Regression test: when it fails, it tells you that the application no longer behaves the way it used to.

Answer 5

Briefly:

Unit testing - You unit test each individual piece of code. Think each file or class.

Integration testing - When putting several units together that interact you need to conduct Integration testing to make sure that integrating these units together has not introduced any errors.

Regression testing - after integrating (and maybe fixing) you should run your unit tests again. This is regression testing to ensure that further changes have not broken any units that were already tested. The unit testing you already did has produced the unit tests that can be run again and again for regression testing.

Acceptance tests - when a user/customer/business receive the functionality they (or your test department) will conduct Acceptance tests to ensure that the functionality meets their requirements.

You might also like to investigate white box and black box testing. There are also performance and load testing, and testing of the "'ilities" to consider.

Answer 6

Here's a simple explanation for each of the mentioned tests and when they are applicable:

Unit Test A unit test is performed on a self-contained unit (usually a class or method) and should be performed whenever a unit has been implemented or updating of a unit has been completed.

This means it's run whenever you've written a class/method, fixed a bug, changed functionality...

Integration Test Integration test aims to test how well several units interact with each other. This type of test should be performed Whenever a new form of communications has been established between units or the nature of their interaction have changed.

This means it's run whenever a recently written unit is integrated into the rest of the system or whenever a unit which is interacts with other systems has been updated (and successfully completed its unit tests).

Regression Test Regression tests are performed whenever anything has been changed in the system, in order to check that no new bugs have been introduced.

This means it's run after all patches, upgrades, bug fixes. Regression testing can be seen as a special case of combined unit test and integration test.

Acceptance Test Acceptance tests are performed whenever it is relevant to check that a subsystem (possibly the entire system) fulfils its entire specifications.

This means it's mainly run before finishing a new deliverable or announcing completion of a larger task. See this as your final check to see that you've really completed your goals before running to the client/boss and announcing victory.

This is at least the way I learned, though I'm sure there are other opposing views. Either way, I hope that helps.

Answer 7

I'll try:

1. Unit test: a developer would write one to test an individual component or class.
2. Integration test: a more extensive test that would involve several components or packages that need to collaborate
3. Regression test: Making a single change to an application forces you to re-run ALL the tests and check out ALL the functionality.
4. Acceptance test: End users or QA do these prior to signing off to accept delivery of an application. It says "The app met my requirements."