| Definition |
Testing of isolated portions of source code (modules, functions, or classes) to validate that each unit behaves as expected. :contentReference[oaicite:0]{index=0} |
Testing a complete software system (or a slice of it) to verify that the system functions according to its design and specified requirements. :contentReference[oaicite:1]{index=1} |
Unit: Checking that a function returns the correct result; Functional: Verifying that a login process works correctly end-to-end. |
| Scope |
Focuses on the smallest testable parts of an application – a single “unit” of code. |
Encompasses the overall behavior of the system by testing features or user journeys as specified in design documents or requirements. |
Unit: Testing a “calculateInterest()” function in isolation; Functional: Testing the complete checkout process on an e‑commerce site. |
| Testing Approach |
Typically white‑box (the tester has knowledge of the internal structure) and is often automated; the code is tested in isolation using mocks or stubs. |
Generally black‑box (no knowledge of internal implementation is needed); focuses on providing inputs and validating the outputs against expected behavior. |
Unit: Assert that calling “square(4)” returns “16”; Functional: Enter valid credentials and check that the user is redirected to the dashboard. |
| Who Performs the Tests |
Usually written and executed by developers as part of the coding process (often within a test‑driven development approach). |
Usually executed by QA teams or end users in later stages of the software development lifecycle, though they may also be automated. |
Unit: A developer writes tests for each method before refactoring; Functional: QA executes test cases for a new reporting module before release. |
| Test Environment |
Runs in an isolated environment where dependencies can be simulated (e.g., using stubs, mocks, or fakes) to ensure the unit is tested independently. |
Performed in an environment that closely replicates production, testing the integrated system including all its interfaces. |
Unit: A mock database is used to test a service method; Functional: The entire application is deployed on a test server and its user interface is exercised. |
| Frequency & Timing |
Run very frequently (often on every code commit or as part of continuous integration) to catch defects early. |
Typically executed during system testing or as part of regression testing cycles, and before a final release to verify end‑user requirements. |
Unit: Automated tests run with every build; Functional: A suite of end‑to‑end tests is executed overnight before a release. |
| Purpose & Benefits |
Helps detect errors early in development; serves as a safety net for code changes and supports refactoring by enforcing a “contract” for each unit. |
Ensures that the complete system meets its requirements; validates that user interactions and business processes work as intended. |
Unit: Quickly catching a miscalculation in a helper function; Functional: Detecting that the payment process fails when invalid data is provided. |