Unit testing

Short description: Validating the behavior of isolated source code

Software development

Core activities

* Processes
* Requirements
* Design
* Engineering
* Construction
* Testing
* Debugging
* Deployment
* Maintenance

Paradigms and models

* Agile
* Cleanroom
* Incremental
* Prototyping
* Spiral
* V model
* Waterfall

Methodologies and frameworks

* ASD
* DevOps
* DAD
* DSDM
* FDD
* IID
* Kanban
* Lean SD
* LeSS
* MDD
* MSF
* PSP
* RAD
* RUP
* SAFe
* Scrum
* SEMAT
* TSP
* UP
* XP

Supporting disciplines

* Configuration management
* Documentation
* Software quality assurance (SQA)
* Project management
* User experience

Practices

* ATDD
* BDD
* CCO
* CI
* CD
* DDD
* PP
* SBE
* Stand-up
* TDD

Tools

* Compiler
* Debugger
* Profiler
* GUI designer
* Modeling
* IDE
* Build automation
* Release automation
* Infrastructure as code
* Testing

Standards and Bodies of Knowledge

* BABOK
* CMMI
* IEEE standards
* ISO 9001
* ISO/IEC standards
* PMBOK
* SWEBOK
* ITIL

Glossaries

* Artificial intelligence
* Computer science
* Electrical and electronics engineering

* v
* t
* e

Unit testing, a.k.a. component or module testing, is a form of software testing by which isolated source code is tested to validate expected behavior.[1]

Unit testing describes tests that are run at the unit-level to contrast testing at the integration or system level.[2]

## Contents

* 1 History
* 2 Unit
* 3 Execution
* 4 Testing criteria
* 5 Test case
* 6 Test double
* 7 Parameterized test
* 8 Code visibility
* 9 Test-driven development
* 10 Value
* 10.1 Early detection of problems in the development cycle
* 10.2 Reduced cost
* 10.3 More frequent releases
* 10.4 Allows for code refactoring
* 10.5 Detects changes which may break a design contract
* 10.6 Reduce uncertainty
* 10.7 Documentation of system behavior
* 11 Limitations and disadvantages
* 11.1 Difficulty in setting up realistic and useful tests
* 11.2 Requires discipline throughout the development process
* 11.3 Requires version control
* 11.4 Requires regular reviews
* 11.5 Limitations for embedded system software
* 11.6 Limitations for testing integration with external systems
* 12 Examples
* 12.1 JUnit
* 13 As executable specifications
* 14 Applications
* 14.1 Extreme programming
* 14.2 Automated testing frameworks
* 14.3 Language-level unit testing support
* 15 See also
* 16 References
* 17 Further reading
* 18 External links

## History

Unit testing, as a principle for testing separately smaller parts of large software systems, dates back to the early days of software engineering. In June 1956 at US Navy's Symposium on Advanced Programming Methods for Digital Computers, H.D. Benington presented the SAGE project. It featured a specification-based approach where the coding phase was followed by "parameter testing" to validate component subprograms against their specification, followed then by an "assembly testing" for parts put together.[3][4]

In 1964, a similar approach is described for the software of the Mercury project, where individual units developed by different programmers underwent "unit tests" before being integrated together.[5] In 1969, testing methodologies appear more structured, with unit tests, component tests and integration tests collectively validating individual parts written separately and their progressive assembly into larger blocks.[6] Some public standards adopted in the late 1960s, such as MIL-STD-483[7] and MIL-STD-490, contributed further to a wide acceptance of unit testing in large projects.

Unit testing was in those times interactive[4] or automated,[8] using either coded tests or capture and replay testing tools. In 1989, Kent Beck described a testing framework for Smalltalk (later called SUnit) in "Simple Smalltalk Testing: With Patterns". In 1997, Kent Beck and Erich Gamma developed and released JUnit, a unit test framework that became popular with Java developers.[9] Google embraced automated testing around 2005–2006.[10]

## Unit

A unit is defined as a single behaviour exhibited by the system under test (SUT), usually corresponding to a requirement[definition needed]. While a unit may correspond to a single function or module (in procedural programming) or a single method or class (in object-oriented programming), functions/methods and modules/classes do not necessarily correspond to units. From the system requirements perspective only the perimeter of the system is relevant, thus only entry points to externally visible system behaviours define units.[clarification needed][11]

## Execution

Unit tests can be performed manually or via automated test execution. Automated tests include benefits such as: running tests often, running tests without staffing cost, and consistent and repeatable testing.

Testing is often performed by the programmer who writes and modifies the code under test. Unit testing may be viewed as part of the process of writing code.

## Testing criteria

During development, a programmer may code criteria, or results that are known to be good, into the test to verify the unit's correctness.

During test execution, frameworks log tests that fail any criterion and report them in a summary.

For this, the most commonly used approach is test - function - expected value.

## Test case

This section is an excerpt from Test case (software)[ edit ]

## Test double

This section is an excerpt from Test double[ edit ]

A test double is software used in software test automation that satisfies a dependency so that the test need not depend on production code. A test double provides functionality via an interface that the software under test cannot distinguish from production code.

## Parameterized test

A parameterized test is a test that accepts a set of values that can be used to enable the test to run with multiple, different input values. A testing framework that supports parametrized tests supports a way to encode parameter sets and to run the test with each set.

Use of parametrized tests can reduce test code duplication.

Parameterized tests are supported by TestNG, JUnit,[12] XUnit and NUnit, as well as in various JavaScript test frameworks. Parameters for the unit tests may be coded manually or in some cases are automatically generated by the test framework. In recent years support was added for writing more powerful (unit) tests, leveraging the concept of theories, test cases that execute the same steps, but using test data generated at runtime, unlike regular parameterized tests that use the same execution steps with input sets that are pre-defined.[13]

## Code visibility

Test code needs access to the code it is testing, but testing should not compromise normal design goals such as information hiding, encapsulation and the separation of concerns. To enable access to code not exposed in the external API, unit tests can be located in the same project or module as the code being tested.

In object oriented design this still may not provide access to private data and methods. Therefore, extra work may be necessary for unit tests. In Java and other languages, a developer can use reflection to access private fields and methods.[14] Alternatively, an inner class can be used to hold the unit tests so they have visibility of the enclosing class's members and attributes. In the .NET Framework and some other programming languages, partial classes may be used to expose private methods and data for the tests to access.

It is important that code solely for accommodating tests does not remain in the production code. In C and other languages, compiler directives such as `#if DEBUG ... #endif` can be placed around such additional classes and indeed all other test-related code to prevent them being compiled into the released code. This means the released code is not exactly the same as what was unit tested. The regular running of fewer but more comprehensive, end-to-end, integration tests on the final release build can ensure (among other things) that no production code exists that subtly relies on aspects of the test harness.

There is some debate among developers, as to whether it is wise to test private methods and data anyway. Some argue that private members are a mere implementation detail that may change, and should be allowed to do so without breaking numbers of tests. Thus it should be sufficient to test any class through its public interface or through its subclass interface, which some languages call the "protected" interface.[15] Others say that crucial aspects of functionality may be implemented in private methods and testing them directly offers advantage of smaller and more direct unit tests.[16][17]

## Test-driven development

Main article: Test-driven development

In test-driven development (TDD), unit tests are written before the related production code is written. Starting with a failing test, then adds just enough production code to make the test pass, then refactors the code as makes sense and then repeats by adding another failing test.

## Value

Unit testing is intended to ensure that the units meet their design and behave as intended.[18]

By writing tests first for the smallest testable units, then the compound behaviors between those, one can build up comprehensive tests for complex applications.[18]

One goal of unit testing is to isolate each part of the program and show that the individual parts are correct.[1] A unit test provides a strict, written contract that the piece of code must satisfy.

### Early detection of problems in the development cycle

Unit testing finds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit. The process of writing a thorough set of tests forces the author to think through inputs, outputs, and error conditions, and thus more crisply define the unit's desired behavior.[19]

### Reduced cost

The cost of finding a bug before coding begins or when the code is first written is considerably lower than the cost of detecting, identifying, and correcting the bug later. Bugs in released code may also cause costly problems for the end-users of the software.[20][21][22] Code can be impossible or difficult to unit test if poorly written, thus unit testing can force developers to structure functions and objects in better ways.

### More frequent releases

Unit testing enables more frequent releases in software development. By testing individual components in isolation, developers can quickly identify and address issues, leading to faster iteration and release cycles.[23]

### Allows for code refactoring

Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be identified quickly.

### Detects changes which may break a design contract

Unit tests detect changes which may break a design contract.

### Reduce uncertainty

### Documentation of system behavior

Some programmers contend that unit tests provide a form of documentation of the code. Developers wanting to learn what functionality is provided by a unit, and how to use it, can review the unit tests to gain an understanding of it.[24]

In some processes, the act of writing tests and the code under test, plus associated refactoring, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior.[25]

## Limitations and disadvantages

An elaborate hierarchy of unit tests does not equal integration testing. Integration with peripheral units should be included in integration tests, but not in unit tests. Integration testing typically still relies heavily on humans testing manually; high-level or global-scope testing can be difficult to automate, such that manual testing often appears faster and cheaper.{{Citation needed|date=January 2010} Software testing is a combinatorial problem. For example, every Boolean decision statement requires at least two tests: one with an outcome of "true" and one with an outcome of "false". As a result, for every line of code written, programmers often need 3 to 5 lines of test code. This obviously takes time and its investment may not be worth the effort. There are problems that cannot easily be tested at all - for example those that are nondeterministic or involve multiple threads. In addition, code for a unit test is as likely to be buggy as the code it is testing. Fred Brooks in The Mythical Man-Month quotes: "Never go to sea with two chronometers; take one or three."[26] (If two chronometers contradict, one cannot know which is correct.)

### Difficulty in setting up realistic and useful tests

Another challenge related to writing the unit tests is the difficulty of setting up realistic and useful tests. It is necessary to create relevant initial conditions so the part of the application being tested behaves like part of the complete system. If these initial conditions are not set correctly, the test will not be exercising the code in a realistic context, which diminishes the value and accuracy of unit test results.[27]

### Requires discipline throughout the development process

To obtain the intended benefits from unit testing, rigorous discipline is needed throughout the software development process.

### Requires version control

### Requires regular reviews

It is also essential to implement a sustainable process for ensuring that test case failures are reviewed regularly and addressed immediately.[28] If such a process is not implemented and ingrained into the team's workflow, the application will evolve out of sync with the unit test suite, increasing false positives and reducing the effectiveness of the test suite.

### Limitations for embedded system software

Unit testing embedded system software presents challenges because the software is being developed on a different platform than the one it will eventually run on, making it difficult to run a test program in the actual deployment environment, as is possible with desktop programs.[29]

### Limitations for testing integration with external systems

Unit tests tend to be easiest when a method has input parameters and some output. It is not as easy to create unit tests when a major function of the method is to interact with something external to the application. For example, a method that will work with a database might require a mock up of database interactions to be created, which probably won't be as comprehensive as the real database interactions.[30]

## Examples

### JUnit

Below is an example of a JUnit test suite. It focuses on the `Adder` class.

class Adder {
public int add(int a, int b) {
return a + b;

The test suite uses assert statements to verify the expected result of various input values to the `sum` method.

import static org.junit.Assert.assertEquals;
import org.junit.Test;
public class AdderUnitTest {
@Test
public void sumReturnsZeroForZeroInput() {
Adder adder = new Adder();
assertEquals(0, adder.add(0, 0));

@Test
public void sumReturnsSumOfTwoPositiveNumbers() {
Adder adder = new Adder();
assertEquals(3, adder.add(1, 2));

@Test
public void sumReturnsSumOfTwoNegativeNumbers() {
Adder adder = new Adder();
assertEquals(-3, adder.add(-1, -2));

@Test
public void sumReturnsSumOfLargeNumbers() {
Adder adder = new Adder();
assertEquals(2222, adder.add(1234, 988));

## As executable specifications

Using unit-tests as a design specification has one significant advantage over other design methods: The design document (the unit-tests themselves) can itself be used to verify the implementation. The tests will never pass unless the developer implements a solution according to the design.

Unit testing lacks some of the accessibility of a diagrammatic specification such as a UML diagram, but they may be generated from the unit test using automated tools. Most modern languages have free tools (usually available as extensions to IDEs). Free tools, like those based on the xUnit framework, outsource to another system the graphical rendering of a view for human consumption.[31]

## Applications

### Extreme programming

Unit testing is the cornerstone of extreme programming, which relies on an automated unit testing framework. This automated unit testing framework can be either third party, e.g., xUnit, or created within the development group.

Extreme programming uses the creation of unit tests for test-driven development. The developer writes a unit test that exposes either a software requirement or a defect. This test will fail because either the requirement isn't implemented yet, or because it intentionally exposes a defect in the existing code. Then, the developer writes the simplest code to make the test, along with other tests, pass.

Most code in a system is unit tested, but not necessarily all paths through the code. Extreme programming mandates a "test everything that can possibly break" strategy, over the traditional "test every execution path" method. This leads developers to develop fewer tests than classical methods, but this isn't really a problem, more a restatement of fact, as classical methods have rarely ever been followed methodically enough for all execution paths to have been thoroughly tested.[32] Extreme programming simply recognizes that testing is rarely exhaustive (because it is often too expensive and time-consuming to be economically viable) and provides guidance on how to effectively focus limited resources.

Crucially, the test code is considered a first class project artifact in that it is maintained at the same quality as the implementation code, with all duplication removed. Developers release unit testing code to the code repository in conjunction with the code it tests. Extreme programming's thorough unit testing allows the benefits mentioned above, such as simpler and more confident code development and refactoring, simplified code integration, accurate documentation, and more modular designs. These unit tests are also constantly run as a form of regression test.

Unit testing is also critical to the concept of Emergent Design, which develops software design iteratively through short test-driven development cycles of writing a unit test, making it pass, and refactoring; unit tests provide the regression safety net that makes continuous refactoring safe.[33]

### Automated testing frameworks

An automated testing framework provides features for automating test execution and can accelerate writing and running tests. Frameworks have been developed for a wide variety of programming languages.

Generally, frameworks are third-party, not distributed with a compiler or integrated development environment (IDE).

Tests can be written without using a framework to exercise the code under test using assertions, exception handling, and other control flow mechanisms to verify behavior and report failure. Some note that testing without a framework is valuable since there is a barrier to entry for the adoption of a framework, and that having some tests is better than none – but once a framework is in place, adding tests can be easier.[34]

In some frameworks advanced test features are missing and must be hand-coded.

### Language-level unit testing support

Some programming languages directly support unit testing. Their grammar allows the direct declaration of unit tests without importing a library (whether third party or standard). Additionally, the Boolean conditions of the unit tests can be expressed in the same syntax as Boolean expressions used in non-unit test code, such as what is used for `if` and `while` statements.

Languages with built-in unit testing support include:

* Cobra
* D[35]
* Rust[36]

Languages with standard unit testing framework support include:

* Apex
* Crystal[37]
* Erlang
* Go[38]
* Julia[39]
* LabVIEW
* MATLAB
* Python[40]
* Racket[41][42]
* Ruby[43]
* Swift

Some languages do not have built-in unit-testing support but have established unit testing libraries or frameworks. These languages include:

* ABAP
* C++
* C#
* Clojure[44]
* Elixir
* Java
* JavaScript
* Objective-C
* Perl
* PHP
* PowerShell[45]
* R with testthat
* Scala
* Tcl
* Visual Basic .NET
* Xojo with XojoUnit

## See also

* Acceptance testing
* Characterization test
* Component-based usability testing
* Design predicates
* Design by contract
* Extreme programming
* Functional testing
* Integration testing
* List of unit testing frameworks
* Regression testing
* Software archaeology
* Software testing
* System testing
* Test case
* Test-driven development
* xUnit - a family of unit testing frameworks.

## References

1. ↑ 1.0 1.1 Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 75. ISBN 978-0-470-04212-0.
2. ↑ Amazon Web Services (AWS). (n.d.). What is Unit Testing?. Retrieved May 2, 2025, from [1](https://aws.amazon.com/what-is/unit-testing/)
3. ↑ Benington, Herbert D. (1956). "Production of large computer programs". Proceedings of the Symposium on Advanced Programming Methods for Digital Computers, Washington, D.C., June 28–29, 1956 (Office of Naval Research, Department of the Navy): 15–28.
4. ↑ 4.0 4.1 Benington, H. D. (1987-03-01). "Production of large computer programs (reprint of the 1956 paper with an updated foreword)". Proceedings of the 9th International Conference on Software Engineering. ICSE '87 (Washington, DC, USA: IEEE Computer Society Press): 299–310. ISBN 978-0-89791-216-7. https://dl.acm.org/doi/10.5555/41765.41799.
5. ↑ Donegan, James J.; Packard, Calvin; Pashby, Paul (1964-01-01). "Experiences with the goddard computing system during manned spaceflight missions". Proceedings of the 1964 19th ACM national conference. ACM '64. New York, NY, USA: Association for Computing Machinery. pp. 12.101–12.108. doi:10.1145/800257.808889. ISBN 978-1-4503-7918-2. https://dl.acm.org/doi/10.1145/800257.808889.
6. ↑ Zimmerman, Norman A. (1969-08-26). "System integration as a programming function". Proceedings of the 1969 24th national conference. ACM '69. New York, NY, USA: Association for Computing Machinery. pp. 459–467. doi:10.1145/800195.805951. ISBN 978-1-4503-7493-4. https://dl.acm.org/doi/10.1145/800195.805951.
7. ↑ MIL-STD-483 Military standard: configuration management practices for systems, equipment, munitions, and computer programs. United states, Department of Defense. 1970-12-31. pp. Section 3.4.7.2. "The contractor shall then code and test software Units, and enter the source and object code, and associated listings of each successfully tested Unit into the Developmental Configuration"
8. ↑ Tighe, Michael F. (1978-01-01). "The value of a proper software quality assurance methodology". ACM SIGMETRICS Performance Evaluation Review 7 (3–4): 165–172. doi:10.1145/1007775.811118. ISSN 0163-5999. https://dl.acm.org/doi/10.1145/1007775.811118.
9. ↑ Gulati, Shekhar (2017). Java Unit Testing with JUnit 5 : Test Driven Development with JUnit 5. Rahul Sharma. Berkeley, CA: Apress. pp. 8. ISBN 978-1-4842-3015-2. OCLC 1012347252.
10. ↑ Winters, Titus (2020). Software engineering at Google : lessons learned from programming over time. Tom Manshreck, Hyrum Wright (1st ed.). Sebastopol, CA: O'Reilly. ISBN 978-1-4920-8274-3. OCLC 1144086840.
11. ↑ Beck, Kent (2002). Test-Driven Development by Example. Addison-Wesley. ISBN 978-0321146533.
12. ↑ Gulati & Sharma 2017, pp. 133–137, Chapter §7 JUnit 5 Extension Model - Parameterized Test.
13. ↑ Kampmann, Alexander; Zeller, Andreas (May 2019). "Carving Parameterized Unit Tests". 2019 IEEE/ACM 41st International Conference on Software Engineering: Companion Proceedings (ICSE-Companion). pp. 248–249. doi:10.1109/icse-companion.2019.00098. ISBN 978-1-7281-1764-5.
14. ↑ Burton, Ross (2003-11-12). "Subverting Java Access Protection for Unit Testing". O'Reilly Media, Inc.. http://www.onjava.com/pub/a/onjava/2003/11/12/reflection.html.
15. ↑ van Rossum, Guido; Warsaw, Barry (5 July 2001). "PEP 8 -- Style Guide for Python Code". Python Software Foundation. https://www.python.org/dev/peps/pep-0008/.
16. ↑ Newkirk, James (7 June 2004). "Testing Private Methods/Member Variables - Should you or shouldn't you". Microsoft Corporation. http://blogs.msdn.com/jamesnewkirk/archive/2004/06/07/150361.aspx.
17. ↑ Stall, Tim (1 Mar 2005). "How to Test Private and Protected methods in .NET". CodeProject. http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx.
18. ↑ 18.0 18.1 Hamill, Paul (2004). Unit Test Frameworks: Tools for High-Quality Software Development. O'Reilly Media, Inc.. ISBN 9780596552817. https://books.google.com/books?id=2ksvdhhnWQsC.
19. ↑ Gren, Lucas; Antinyan, Vard (August 2017). "On the Relation Between Unit Testing and Code Quality". 43rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA). pp. 52–56. doi:10.1109/seaa.2017.36. https://ieeexplore.ieee.org/document/8051327/. Retrieved 2026-05-16.
20. ↑ Boehm, Barry W.; Papaccio, Philip N. (October 1988). "Understanding and Controlling Software Costs". IEEE Transactions on Software Engineering 14 (10): 1462–1477. doi:10.1109/32.6191. Bibcode: 1988ITSEn..14.1462B. http://faculty.ksu.edu.sa/ghazy/Cost_MSc/R6.pdf. Retrieved 13 May 2016.
21. ↑ "Test Early and Often". Microsoft. https://msdn.microsoft.com/en-us/library/ee330950(v=vs.110).aspx.
22. ↑ "Prove It Works: Using the Unit Test Framework for Software Testing and Validation". National Instruments. 2017-08-21. http://www.ni.com/white-paper/8082/en/.
23. ↑ Erik (10 March 2023). "You Still Don't Know How to Do Unit Testing (and Your Secret is Safe with Me)". https://stackify.com/unit-testing-basics-best-practices/.
24. ↑ Stocker, Karsten; Washizaki, Hironori; Fukazawa, Yoshiaki (March 2017). "Closing the Gap between Unit Test Code and Documentation". 2017 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW). pp. 304–308. doi:10.1109/icstw.2017.56. ISBN 978-1-5090-6676-6.
25. ↑ Nassif, M.; Hernandez, Alexa; Sridharan, Ashvitha; Robillard, M. (2022). "Generating Unit Tests for Documentation". IEEE Transactions on Software Engineering 48 (9): 3268–3279. doi:10.1109/TSE.2021.3087087. Bibcode: 2022ITSEn..48.3268N.
26. ↑ Brooks, Frederick J. (1995). The Mythical Man-Month. Addison-Wesley. p. 64. ISBN 978-0-201-83595-3.
27. ↑ Tiwari, Deepika; Monperrus, Martin; Baudry, Benoit (November 2024). "Mimicking Production Behavior With Generated Mocks". IEEE Transactions on Software Engineering 50 (11): 2921–2946. doi:10.1109/tse.2024.3458448. ISSN 2326-3881. Bibcode: 2024ITSEn..50.2921T.
28. ↑ daVeiga, Nada (2008-02-06). "Change Code Without Fear: Utilize a regression safety net". http://www.ddj.com/development-tools/206105233.
29. ↑ Kucharski, Marek (2011-11-23). "Making Unit Testing Practical for Embedded Development". https://www.electronicdesign.com/technologies/embedded-revolution/article/21794376/making-unit-testing-practical-for-embedded-development.
30. ↑ "Unit Tests And Databases". http://wiki.c2.com/?UnitTestsAndDatabases.
31. ↑ GeeksforGeeks. (2024). Unit Testing. Retrieved May 2, 2025, from [2](https://www.geeksforgeeks.org/unit-testing-software-testing/)
32. ↑ Beck, Kent (October 1999). "Extreme Programming Explained: Embrace Change". Computer 32 (10): 70–76. doi:10.1109/52.844236. https://doi.org/10.1109/52.844236. Retrieved 2026-05-07.
33. ↑ Fucci, Davide; Erdogmus, Hakan; Turhan, Burak; Oivo, Markku; Juristo, Natalia (2017). "A Dissection of the Test-Driven Development Process: Does It Really Matter to Test-First or to Test-Last?". IEEE Transactions on Software Engineering 43 (7): 597–614. doi:10.1109/tse.2016.2616877. ISSN 1939-3520. https://ieeexplore.ieee.org/document/7592412/. Retrieved 2026-05-25.
34. ↑ Bullseye Testing Technology (2006–2008). "Intermediate Coverage Goals". http://www.bullseye.com/coverage.html.
35. ↑ "Unit Tests - D Programming Language". D Language Foundation. http://dlang.org/spec/unittest.html.
36. ↑ Steve Klabnik and Carol Nichols, with contributions from the Rust Community (2015–2023). "How to Write Tests". https://doc.rust-lang.org/book/ch11-01-writing-tests.html.
37. ↑ "Crystal Spec". crystal-lang.org. https://crystal-lang.org/api/0.23.1/Spec.html.
38. ↑ "testing - The Go Programming Language". golang.org. http://golang.org/pkg/testing/.
39. ↑ "Unit Testing · The Julia Language". docs.julialang.org. https://docs.julialang.org/en/v1/stdlib/Test/.
40. ↑ Python Documentation (2016). "unittest -- Unit testing framework". https://docs.python.org/3/library/unittest.html.
41. ↑ Welsh, Noel; Culpepper, Ryan. "RackUnit: Unit Testing". PLT Design Inc.. http://docs.racket-lang.org/rackunit/index.html.
42. ↑ Welsh, Noel; Culpepper, Ryan. "RackUnit Unit Testing package part of Racket main distribution". PLT Design Inc.. https://pkgs.racket-lang.org/package/rackunit.
43. ↑ "Minitest (Ruby 2.0)". Ruby-Doc.org. http://ruby-doc.org/stdlib-2.0.0/libdoc/minitest/rdoc/MiniTest.html.
44. ↑ Sierra, Stuart. "API for clojure.test - Clojure v1.6 (stable)". https://clojure.github.io/clojure/clojure.test-api.html.
45. ↑ "Pester Framework". https://github.com/pester/Pester.

## Further reading

* Feathers, Michael C. (2005). Working Effectively with Legacy Code. Upper Saddle River, NJ: Prentice Hall Professional Technical Reference. ISBN 978-0131177055.
* Gulati, Shekhar; Sharma, Rahul (2017). Java Unit Testing with JUnit 5. Apress.

## External links

* Test Driven Development (Ward Cunningham's Wiki)

Template:Software testing

0.00

(0 votes)

Original source: https://en.wikipedia.org/wiki/Unit testing. Read more

|

Retrieved from "https://handwiki.org/wiki/index.php?title=Unit_testing&oldid=4418358"
*[v]: View this template
*[t]: Discuss this template
*[e]: Edit this template
*[a.k.a.]: also known as