Unit testing ============ From Wikipedia, the free encyclopedia Jump to navigation Jump to search Software testing method by which individual units of source code are validated `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`_ + `OpenUP`_ + `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`_ + `IREB`_ Glossaries + `Artificial intelligence`_ + `Computer science`_ + `Electrical and electronics engineering`_ Outlines + `Outline of software development`_ + ` v `_ + ` t `_ + ` e `_ In `computer programming`_, **unit testing** is a `software testing`_ method by which individual units of `source code`_sets of one or more computer program modules together with associated control data, usage procedures, and operating proceduresare tested to determine whether they are fit for use. [1] Contents -------- + 1 Description + 2 Advantages + 3 Limitations and disadvantages + 4 Example + 5 As executable specifications + 6 Applications + 6.1 Extreme programming + 6.2 Unit testing frameworks + 6.3 Language-level unit testing support + 7 See also + 8 References + 9 External links Description[`edit`_] -------------------- ` `_ This section **needs additional citations for `verification`_**. Please help `improve this article`_ by `adding citations to reliable sources`_. Unsourced material may be challenged and removed. (September 2019) (`Learn how and when to remove this template message`_) Unit tests are typically `automated`_ tests written and run by `software developers`_ to ensure that a section of an application (known as the "unit") meets its design and behaves as intended. [2] In `procedural programming`_, a unit could be an entire module, but it is more commonly an individual function or procedure. In `object-oriented programming`_, a unit is often an entire interface, such as a class, but could be an individual method. [3] By writing tests first for the smallest testable units, then the compound behaviors between those, one can build up comprehensive tests for complex applications. [2] To isolate issues that may arise, each `test case`_ should be tested independently. Substitutes such as `method stubs`_, `mock objects`_, [4] `fakes`_, and `test harnesses`_ can be used to assist testing a module in isolation. During development, a software developer may code criteria, or results that are known to be good, into the test to verify the unit's correctness. During test case execution, frameworks `log`_ tests that fail any criterion and report them in a summary. Writing and maintaining unit tests can be made faster by using `parameterized tests`_. These allow the execution of one test multiple times with different input sets, thus reducing test code duplication. Unlike traditional unit tests, which are usually closed methods and test invariant conditions, parameterized tests take any set of parameters. Parameterized tests are supported by `TestNG`_, `JUnit`_ and its .Net counterpart, `XUnit`_. Suitable parameters for the unit tests may be supplied 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. [5] [6] [7] Advantages[`edit`_] ------------------- The 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. As a result, it affords several benefits. 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. 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. [8] [9] [10] 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. In `test-driven development`_ (TDD), which is frequently used in both `extreme programming`_ and `scrum`_, unit tests are created before the code itself is written. When the tests pass, that code is considered complete. The same unit tests are run against that function frequently as the larger code base is developed either as the code is changed or via an automated process with the build. If the unit tests fail, it is considered to be a bug either in the changed code or the tests themselves. The unit tests then allow the location of the fault or failure to be easily traced. Since the unit tests alert the development team of the problem before handing the code off to testers or clients, potential problems are caught early in the development process. 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 quickly identified. Unit tests detect changes which may break a `design contract`_. Unit testing may reduce uncertainty in the units themselves and can be used in a `bottom-up`_ testing style approach. By testing the parts of a program first and then testing the sum of its parts, `integration testing`_ becomes much easier. [ `citation needed`_ ] Unit testing provides a sort of living documentation of the system. Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface (`API`_). [ `citation needed`_ ] Unit `test cases`_ embody characteristics that are critical to the success of the unit. These characteristics can indicate appropriate/inappropriate use of a unit as well as negative behaviors that are to be trapped by the unit. A unit test case, in and of itself, documents these critical characteristics, although many software development environments do not rely solely upon code to document the product in development. [ `citation needed`_ ] When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test has passed, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behavior. [ `citation needed`_ ] Limitations and disadvantages[`edit`_] -------------------------------------- Testing will not catch every error in the program, because it cannot evaluate every execution path in any but the most trivial programs. This `problem`_ is a superset of the `halting problem`_, which is `undecidable`_. The same is true for unit testing. Additionally, unit testing by definition only tests the functionality of the units themselves. Therefore, it will not catch integration errors or broader system-level errors (such as functions performed across multiple units, or non-functional test areas such as `performance`_). Unit testing should be done in conjunction with other `software testing`_ activities, as they can only show the presence or absence of particular errors; they cannot prove a complete absence of errors. To guarantee correct behavior for every execution path and every possible input, and ensure the absence of errors, other techniques are required, namely the application of `formal methods`_ to proving that a software component has no unexpected behavior. [ `citation needed`_ ] 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. [ `citation needed`_ ] 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`_ ] 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. [11] 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 likely to be at least as 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." [12] Meaning, if two `chronometers`_ contradict, how do you know which one is correct? 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. [13] To obtain the intended benefits from unit testing, rigorous discipline is needed throughout the software development process. It is essential to keep careful records not only of the tests that have been performed, but also of all changes that have been made to the source code of this or any other unit in the software. Use of a `version control`_ system is essential. If a later version of the unit fails a particular test that it had previously passed, the version-control software can provide a list of the source code changes (if any) that have been applied to the unit since that time. [ `citation needed`_ ] It is also essential to implement a sustainable process for ensuring that test case failures are reviewed regularly and addressed immediately. [14] 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. Unit testing embedded system software presents a unique challenge: Because the software is being developed on a different platform than the one it will eventually run on, you cannot readily run a test program in the actual deployment environment, as is possible with desktop programs. [15] 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. [16] [ `bettersourceneeded`_ ] Example[`edit`_] ---------------- Here is a set of test cases in `Java`_ that specify a number of elements of the implementation. First, that there must be an interface called Adder, and an implementing class with a zero-argument constructor called AdderImpl. It goes on to `assert`_ that the Adder interface should have a method called add, with two integer parameters, which returns another integer. It also specifies the behaviour of this method for a small range of values over a number of test methods. :: import static org.junit.Assert.*; import org.junit.Test; public class TestAdder { @Test public void testSumPositiveNumbersOneAndOne() { Adder adder = new AdderImpl(); assert(adder.add(1, 1) == 2); } // can it add the positive numbers 1 and 2? @Test public void testSumPositiveNumbersOneAndTwo() { Adder adder = new AdderImpl(); assert(adder.add(1, 2) == 3); } // can it add the positive numbers 2 and 2? @Test public void testSumPositiveNumbersTwoAndTwo() { Adder adder = new AdderImpl(); assert(adder.add(2, 2) == 4); } // is zero neutral? @Test public void testSumZeroNeutral() { Adder adder = new AdderImpl(); assert(adder.add(0, 0) == 0); } // can it add the negative numbers -1 and -2? @Test public void testSumNegativeNumbers() { Adder adder = new AdderImpl(); assert(adder.add(-1, -2) == -3); } // can it add a positive and a negative? @Test public void testSumPositiveAndNegative() { Adder adder = new AdderImpl(); assert(adder.add(-1, 1) == 0); } // how about larger numbers? @Test public void testSumLargeNumbers() { Adder adder = new AdderImpl(); assert(adder.add(1234, 988) == 2222); } } In this case the unit tests, having been written first, act as a design document specifying the form and behaviour of a desired solution, but not the implementation details, which are left for the programmer. Following the "do the simplest thing that could possibly work" practice, the easiest solution that will make the test pass is shown below. :: interface Adder { int add(int a, int b); } class AdderImpl implements Adder { public int add(int a, int b) { return a + b; } } As executable specifications[`edit`_] ------------------------------------- ` `_ This section **does not `cite`_ any `sources`_**. Please help `improve this section`_ by `adding citations to reliable sources`_. Unsourced material may be challenged and `removed`_. (September 2019) (`Learn how and when to remove this template message`_) 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. Applications[`edit`_] --------------------- Extreme programming[`edit`_] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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. [ `citation needed`_ ] 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`_. As emergent design is heavily dependent upon refactoring, unit tests are an integral component. [17] Unit testing frameworks[`edit`_] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See also: `List of unit testing frameworks`_ Unit testing frameworks are most often third-party products that are not distributed as part of the compiler suite. They help simplify the process of unit testing, having been developed for `a wide variety of languages`_. It is generally possible to perform unit testing without the support of a specific framework by writing client code that exercises the units under test and uses `assertions`_, `exception handling`_, or other `control flow`_ mechanisms to signal failure. Unit testing without a framework is valuable in that there is a `barrier to entry`_ for the adoption of unit testing; having scant unit tests is hardly better than having none at all, whereas once a framework is in place, adding unit tests becomes relatively easy. [18] In some frameworks many advanced unit test features are missing or must be hand-coded. Language-level unit testing support[`edit`_] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: + `Apex`_ + `Cobra`_ + `Crystal`_ [19] + `D`_ [20] + `Go`_ [21] + `LabVIEW`_ + `MATLAB`_ + `Python`_ [22] + `Racket`_ [23] [24] + `Ruby`_ [25] + `Rust`_ [26] Some languages without built-in unit-testing support have very good unit testing libraries/frameworks. Those languages include: + `ABAP`_ + `C++`_ + `C#`_ + `Clojure`_ [27] + `Elixir`_ + `Java`_ + `JavaScript`_ + `Objective-C`_ + `Perl`_ + `PHP`_ + `PowerShell`_ [28] + `R`_ with testthat + `Scala`_ + `tcl`_ + `Visual Basic .NET`_ + `Xojo`_ with XojoUnit See also[`edit`_] ----------------- + `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`_ + `Test case`_ + `Test-driven development`_ + `xUnit`_ a family of unit testing frameworks. References[`edit`_] ------------------- #. ^ **a** **b** 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 `_. #. ^ **a** **b** Hamill, Paul (2004). ` Unit Test Frameworks: Tools for High-Quality Software Development `_. O'Reilly Media, Inc. `ISBN`_` 9780596552817 `_. #. **^** `Xie, Tao`_. `"Towards a Framework for Differential Unit Testing of Object-Oriented Programs"`_ (PDF). Retrieved 23 July 2012. #. **^** `Fowler, Martin`_ (2 January 2007). `"Mocks aren't Stubs"`_. Retrieved 1 April 2008. #. **^** `"Getting Started with xUnit.net (desktop)"`_. #. **^** `"Theories"`_. #. **^** `"Parameterized tests"`_. #. **^** `Boehm, Barry W.`_; Papaccio, Philip N. (October 1988). `"Understanding and Controlling Software Costs"`_ (PDF). IEEE Transactions on Software Engineering . **14** (10): 1462ÔÇô1477. `doi`_:`10.1109/32.6191`_. Retrieved 13 May 2016. #. **^** `"Test Early and Often"`_. Microsoft. #. **^** `"Prove It Works: Using the Unit Test Framework for Software Testing and Validation"`_. `National Instruments`_. 21 August 2017. #. **^** `Cramblitt, Bob`_ (20 September 2007). `"Alberto Savoia sings the praises of software testing"`_. Retrieved 29 November 2007. #. **^** `Brooks, Frederick J.`_ (1995) [1975]. ` The Mythical Man- Month `_. Addison-Wesley. p.`64`_. `ISBN`_` 978-0-201-83595-3 `_. #. **^** `Kolawa, Adam`_ (1 July 2009). `"Unit Testing Best Practices"`_. Retrieved 23 July 2012. #. **^** `daVeiga, Nada`_ (6 February 2008). `"Change Code Without Fear: Utilize a regression safety net"`_. Retrieved 8 February 2008. #. **^** `Kucharski, Marek`_ (23 November 2011). `"Making Unit Testing Practical for Embedded Development"`_. Retrieved 20 July 2020. #. **^** `http://wiki.c2.com/?UnitTestsAndDatabases`_ #. **^** `"Agile Emergent Design"`_. Agile Sherpa. 3 August 2010. Archived from `the original`_ on 22 March 2012. Retrieved 8 May 2012. #. **^** Bullseye Testing Technology (2006ÔÇô2008). `"Intermediate Coverage Goals"`_. Retrieved 24 March 2009. #. **^** `"Crystal Spec"`_. crystal-lang.org. Retrieved 18 September 2017. #. **^** `"Unit Tests - D Programming Language"`_. D Programming Language . D Language Foundation. Retrieved 5 August 2017. #. **^** `"testing - The Go Programming Language"`_. golang.org. Retrieved 3 December 2013. #. **^** Python Documentation (2016). `"unittest -- Unit testing framework"`_. Retrieved 18 April 2016. #. **^** Welsh, Noel; Culpepper, Ryan. `"RackUnit: Unit Testing"`_. PLT Design Inc. Retrieved 26 February 2019. #. **^** Welsh, Noel; Culpepper, Ryan. `"RackUnit Unit Testing package part of Racket main distribution"`_. PLT Design Inc. Retrieved 26 February 2019. #. **^** `"Minitest (Ruby 2.0)"`_. Ruby-Doc.org. #. **^** The Rust Project Developers (2011ÔÇô2014). `"The Rust Testing Guide (Rust 0.12.0-pre-nightly)"`_. Retrieved 12 August 2014. #. **^** Sierra, Stuart. `"API for clojure.test - Clojure v1.6 (stable)"`_. Retrieved 11 February 2015. #. **^** `"Pester Framework"`_. Retrieved 28 January 2016. External links[`edit`_] ----------------------- + `Test Driven Development (Ward Cunningham's Wiki)`_ Retrieved from "`https://en.wikipedia.org/w/index.php?title=Unit_testi ng&oldid=968650276`_" `Categories`_: + `Unit testing`_ + `Extreme programming`_ + `Software testing`_ + `Types of tools used in software development`_ Hidden categories: + `Articles with short description`_ + `Short description matches Wikidata`_ + `Use dmy dates from April 2020`_ + `Articles needing additional references from September 2019`_ + `All articles needing additional references`_ + `All articles with unsourced statements`_ + `Articles with unsourced statements from January 2013`_ + `Articles with unsourced statements from September 2019`_ + `Articles with unsourced statements from October 2010`_ + `Articles with unsourced statements from January 2010`_ + `All articles lacking reliable references`_ + `Articles lacking reliable references from February 2019`_ + `Articles with unsourced statements from November 2008`_ + `Articles with example Java code`_ Navigation menu --------------- Personal tools ~~~~~~~~~~~~~~ + Not logged in + `Talk`_ + `Contributions`_ + `Create account`_ + `Log in`_ Namespaces ~~~~~~~~~~ + `Article`_ + `Talk`_ Variants ~~~~~~~~ Views ~~~~~ + `Read`_ + `Edit`_ + `View history`_ More ~~~~ Search ~~~~~~ ``_ Navigation ~~~~~~~~~~ + `Main page`_ + `Contents`_ + `Current events`_ + `Random article`_ + `About Wikipedia`_ + `Contact us`_ + `Donate`_ Contribute ~~~~~~~~~~ + `Help`_ + `Learn to edit`_ + `Community portal`_ + `Recent changes`_ + `Upload file`_ Tools ~~~~~ + `What links here`_ + `Related changes`_ + `Upload file`_ + `Special pages`_ + `Permanent link`_ + `Page information`_ + `Cite this page`_ + `Wikidata item`_ Print/export ~~~~~~~~~~~~ + `Download as PDF`_ + `Printable version`_ In other projects ~~~~~~~~~~~~~~~~~ + `Wikibooks`_ Languages ~~~~~~~~~ + `Ϻ┘äÏ╣Ï▒Ï¿┘èÏ®`_ + `ðæÐèð╗ð│ð░ÐÇÐüð║ð©`_ + `Catal├á`_ + `─îe┼ítina`_ + `Dansk`_ + `Deutsch`_ + `Eesti`_ + `Espa├▒ol`_ + `┘üϺÏ▒Ï│█î`_ + `Fran├ºais`_ + `Ýò£ÛÁ¡ýû┤`_ + `Bahasa Indonesia`_ + `Interlingua`_ + `Italiano`_ + `ÎóÎæοÎÖά`_ + `Magyar`_ + `Nederlands`_ + `µùѵ£¼Þ¬×`_ + `Norsk bokm├Ñl`_ + `Polski`_ + `Portugu├¬s`_ + `ðáÐâÐüÐüð║ð©ð╣`_ + `ðíÐÇð┐Ðüð║ð© / srpski`_ + `Suomi`_ + `Ó«ñÓ««Ó«┐Ó«┤Ó»ì`_ + `T├╝rk├ºe`_ + `ðúð║ÐÇð░Ðùð¢ÐüÐîð║ð░`_ + `Tiß║┐ng Viß╗çt`_ + `õ©¡µûç`_ `Edit links`_ + This page was last edited on 20 July 2020, at 17:31(UTC). + Text is available under the `Creative Commons Attribution-ShareAlike License`_``_; additional terms may apply. By using this site, you agree to the `Terms of Use`_ and `Privacy Policy`_. Wikipedia┬« is a registered trademark of the `Wikimedia Foundation, Inc.`_, a non- profit organization. + `Privacy policy`_ + `About Wikipedia`_ + `Disclaimers`_ + `Contact Wikipedia`_ + `Mobile view`_ + `Developers`_ + `Statistics`_ + `Cookie statement`_ + ` `_ + ` `_ .. _IDEs: /wiki/Integrated_development_environment .. _oldid=968650276: https://en.wikipedia.org/w/index.php?title=Unit_testing&oldid=968650276 .. _Catal├á: https://ca.wikipedia.org/wiki/Proves_unit%C3%A0ries .. _Statistics: https://stats.wikimedia.org/#/en.wikipedia.org .. _tcl: /wiki/Tcl .. _Deployment: /wiki/Software_deployment .. _DevOps: /wiki/DevOps .. _"Mocks aren't Stubs": http://martinfowler.com/articles/mocksArentStubs.html .. _Boehm, Barry W.: /wiki/Barry_Boehm .. _PSP: /wiki/Personal_software_process .. _Python: /wiki/Python_(programming_language) .. _Short description matches Wikidata: /wiki/Category:Short_description_matches_Wikidata .. _"API for clojure.test - Clojure v1.6 (stable)": https://clojure.github.io/clojure/clojure.test-api.html .. _"Intermediate Coverage Goals": http://www.bullseye.com/coverage.html .. _Polski: https://pl.wikipedia.org/wiki/Test_jednostkowy .. _the original: http://www.agilesherpa.org/agile_coach/engineering_practices/emergent_design/ .. _┘üϺÏ▒Ï│█î: https://fa.wikipedia.org/wiki/%D8%A2%D8%B2%D9%85%D8%A7%DB%8C%D8%B4_%D9%88%D8%A7%D8%AD%D8%AF .. _Objective-C: /wiki/Objective-C .. _"Parameterized tests": https://github.com/junit-team/junit4/wiki/Parameterized-tests .. _parameterized tests: /wiki/Parameterized_test .. _Contributions: /wiki/Special:MyContributions .. _bottom-up: /wiki/Top-down_and_bottom-up_design .. _Racket: /wiki/Racket_(programming_language) .. _978-0-201-83595-3: /wiki/Special:BookSources/978-0-201-83595-3 .. _Cleanroom: /wiki/Cleanroom_software_engineering .. _"unittest -- Unit testing framework": https://docs.python.org/3/library/unittest.html .. _Espa├▒ol: https://es.wikipedia.org/wiki/Prueba_unitaria .. _Build automation: /wiki/Build_automation .. _undecidable: /wiki/Undecidable_problem .. _functions: /wiki/Subroutine .. _Norsk bokm├Ñl: https://no.wikipedia.org/wiki/Enhetstesting .. _barrier to entry: /wiki/Barrier_to_entry .. _DAD: /wiki/Disciplined_agile_delivery .. _RUP: /wiki/Rational_Unified_Process .. _UML: /wiki/Unified_Modeling_Language .. _"testing - The Go Programming Language": https://golang.org/pkg/testing/ .. _MDD: /wiki/Model-driven_development .. _"Unit Tests - D Programming Language": http://dlang.org/spec/unittest.html .. _Software archaeology: /wiki/Software_archaeology .. _Unit testing: /wiki/Category:Unit_testing .. _ITIL: /wiki/ITIL .. _V model: /wiki/V-Model_(software_development) .. _Outline of software development: /wiki/Outline_of_software_development .. _Automated Defect Prevention: Best Practices in Software Management: http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html .. _Contents: /wiki/Wikipedia:Contents .. _"RackUnit Unit Testing package part of Racket main distribution": https://pkgs.racket-lang.org/package/rackunit .. _All articles lacking reliable references: /wiki/Category:All_articles_lacking_reliable_references .. _edit: /w/index.php?title=Unit_testing&action=edit§ion=12 .. _Debugging: /wiki/Debugging .. _edit: /w/index.php?title=Unit_testing&action=edit§ion=10 .. _edit: /w/index.php?title=Unit_testing&action=edit§ion=11 .. _Articles lacking reliable references from February 2019: /wiki/Category:Articles_lacking_reliable_references_from_February_2019 .. _Xie, Tao: /w/index.php?title=Tao_Xie&action=edit&redlink=1 .. _User experience: /wiki/User_experience .. _SAFe: /wiki/Scaled_agile_framework .. _procedural programming: /wiki/Procedural_programming .. _C++: /wiki/C%2B%2B .. _exception handling: /wiki/Exception_handling .. _Go: /wiki/Go_(programming_language) .. _õ©¡µûç: https://zh.wikipedia.org/wiki/%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95 .. _Software testing: /wiki/Software_testing .. _Software testing: /wiki/Category:Software_testing .. _T├╝rk├ºe: https://tr.wikipedia.org/wiki/Birim_testi .. _testing manually: /wiki/Manual_testing .. _PowerShell: /wiki/Windows_PowerShell .. _Community portal: /wiki/Wikipedia:Community_portal .. _CI: /wiki/Continuous_integration .. _performance: /wiki/Software_performance_testing .. _GUI designer: /wiki/Graphical_user_interface_builder .. _Incremental: /wiki/Incremental_build_model .. _Test-driven development: /wiki/Test-driven_development .. _Articles with unsourced statements from September 2019: /wiki/Category:Articles_with_unsourced_statements_from_September_2019 .. _9780596552817: /wiki/Special:BookSources/9780596552817 .. _source code: /wiki/Source_code .. _Disclaimers: /wiki/Wikipedia:General_disclaimer .. _SEMAT: /wiki/SEMAT .. _"Crystal Spec": https://crystal-lang.org/api/0.23.1/Spec.html .. _Page information: /w/index.php?title=Unit_testing&action=info .. _ðúð║ÐÇð░Ðùð¢ÐüÐîð║ð░: https://uk.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D1%8C%D0%BD%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F .. _Ϻ┘äÏ╣Ï▒Ï¿┘èÏ®: https://ar.wikipedia.org/wiki/%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1_%D8%A7%D9%84%D9%88%D8%AD%D8%AF%D8%A9 .. _v: /wiki/Template:Software_development_process .. _Log in: /w/index.php?title=Special:UserLogin&returnto=Unit+testing .. _Create account: /w/index.php?title=Special:CreateAccount&returnto=Unit+testing .. _Tiß║┐ng Viß╗çt: https://vi.wikipedia.org/wiki/Ki%E1%BB%83m_th%E1%BB%AD_%C4%91%C6%A1n_v%E1%BB%8B .. _ISO/IEC standards: /wiki/ISO/IEC_JTC_1/SC_7 .. _Methodologies: /wiki/Software_development_methodology .. _Test Driven Development (Ward Cunningham's Wiki): http://c2.com/cgi/wiki?TestDrivenDevelopment .. _Nederlands: https://nl.wikipedia.org/wiki/Unittesten .. _Terms of Use: //foundation.wikimedia.org/wiki/Terms_of_Use .. _Engineering: /wiki/Software_engineering .. _MATLAB: /wiki/MATLAB .. _10.1109/32.6191: https://doi.org/10.1109%2F32.6191 .. _mock objects: /wiki/Mock_object .. _Integration testing: /wiki/Integration_testing .. _Functional testing: /wiki/Functional_testing .. _version control: /wiki/Version_control .. _C#: /wiki/C_Sharp_(programming_language) .. _Cramblitt, Bob: /w/index.php?title=Bob_Cramblitt&action=edit&redlink=1 .. _Characterization test: /wiki/Characterization_test .. _Help: /wiki/Help:Contents .. _methods: /wiki/Method_(computer_science) .. _"Pester Framework": https://github.com/pester/Pester .. _Visual Basic .NET: /wiki/Visual_Basic_.NET .. _"Minitest (Ruby 2.0)": http://ruby-doc.org/stdlib-2.0.0/libdoc/minitest/rdoc/MiniTest.html .. _problem: /wiki/Decision_problem .. _Developers: https://www.mediawiki.org/wiki/Special:MyLanguage/How_to_contribute .. _http://wiki.c2.com/?UnitTestsAndDatabases: http://wiki.c2.com/?UnitTestsAndDatabases .. _IREB: /wiki/International_Requirements_Engineering_Board .. _Bahasa Indonesia: https://id.wikipedia.org/wiki/Pengujian_unit .. _"Making Unit Testing Practical for Embedded Development": https://www.electronicdesign.com/technologies/embedded-revolution/article/21794376/making-unit-testing-practical-for-embedded-development .. _API: /wiki/Application_programming_interface .. _Talk: /wiki/Talk:Unit_testing .. _Kanban: /wiki/Kanban_(development) .. _computer programming: /wiki/Computer_programming .. _formal methods: /wiki/Formal_verification .. _IEEE standards: /wiki/IEEE_Standards_Association .. _Elixir: /wiki/Elixir_(programming_language) .. _LabVIEW: /wiki/LabVIEW .. _JavaScript: /wiki/JavaScript .. _ATDD: /wiki/Acceptance_test%E2%80%93driven_development .. _ÎóÎæοÎÖά: https://he.wikipedia.org/wiki/%D7%91%D7%93%D7%99%D7%A7%D7%95%D7%AA_%D7%99%D7%97%D7%99%D7%93%D7%94 .. _Infrastructure as code: /wiki/Infrastructure_as_code .. _SWEBOK: /wiki/Software_Engineering_Body_of_Knowledge .. _improve this section: https://en.wikipedia.org/w/index.php?title=Unit_testing&action=edit .. _Types of tools used in software development: /wiki/Category:Types_of_tools_used_in_software_development .. _Electrical and electronics engineering: /wiki/Glossary_of_electrical_and_electronics_engineering .. _contract: /wiki/Design_by_Contract .. _Ruby: /wiki/Ruby_(programming_language) .. _PP: /wiki/Pair_programming .. _Processes: /wiki/Software_development_process .. _Agile: /wiki/Agile_software_development .. _daVeiga, Nada: /w/index.php?title=Nada_daVeiga&action=edit&redlink=1 .. _scrum: /wiki/Scrum_(software_development) .. _Articles needing additional references from September 2019: /wiki/Category:Articles_needing_additional_references_from_September_2019 .. _"Prove It Works: Using the Unit Test Framework for Software Testing and Validation": http://www.ni.com/white-paper/8082/en/ .. _sources: /wiki/Wikipedia:Verifiability .. _"Understanding and Controlling Software Costs": http://faculty.ksu.edu.sa/ghazy/Cost_MSc/R6.pdf .. _Cookie statement: https://foundation.wikimedia.org/wiki/Cookie_statement .. _Articles with unsourced statements from January 2010: /wiki/Category:Articles_with_unsourced_statements_from_January_2010 .. _Design by contract: /wiki/Design_by_contract .. _Cobra: /wiki/Cobra_(programming_language) .. _Eesti: https://et.wikipedia.org/wiki/%C3%9Chiktestimine .. _Debugger: /wiki/Debugger .. _Learn to edit: /wiki/Help:Introduction .. _Printable version: /w/index.php?title=Unit_testing&printable=yes .. _chronometers: /wiki/Marine_chronometer .. _Spiral: /wiki/Spiral_model .. _Privacy Policy: //foundation.wikimedia.org/wiki/Privacy_policy .. _Software quality assurance (SQA): /wiki/Software_quality_assurance .. _Contact Wikipedia: //en.wikipedia.org/wiki/Wikipedia:Contact_us .. _Apex: /wiki/Apex_(programming_language) .. _"Test Early and Often": https://msdn.microsoft.com/en-us/library/ee330950%28v=vs.110%29.aspx .. _ISBN: /wiki/ISBN_(identifier) .. _Emergent Design: /wiki/Emergent_Design .. _Crystal: /wiki/Crystal_(programming_language) .. _"Unit Testing Best Practices": http://www.parasoft.com/unit-testing-best-practices .. _Main page: /wiki/Main_Page .. _Ó«ñÓ««Ó«┐Ó«┤Ó»ì: https://ta.wikipedia.org/wiki/%E0%AE%93%E0%AE%B0%E0%AE%B2%E0%AE%95%E0%AF%81%E0%AE%9A%E0%AF%8D_%E0%AE%9A%E0%AF%8B%E0%AE%A4%E0%AE%A9%E0%AF%88 .. _PMBOK: /wiki/Project_Management_Body_of_Knowledge .. _development cycle: /wiki/Development_cycle .. _The Mythical Man-Month: /wiki/The_Mythical_Man-Month .. _Edit: /w/index.php?title=Unit_testing&action=edit .. _citation needed: /wiki/Wikipedia:Citation_needed .. _DSDM: /wiki/Dynamic_systems_development_method .. _Portugu├¬s: https://pt.wikipedia.org/wiki/Teste_de_unidade .. _Edit links: https://www.wikidata.org/wiki/Special:EntityPage/Q907375#sitelinks-wikipedia .. _assert: /wiki/Assertion_(computing) .. _method stubs: /wiki/Method_stub .. _Configuration management: /wiki/Software_configuration_management .. _Talk: /wiki/Special:MyTalk .. _Tools: /wiki/Programming_tool .. _Prototyping: /wiki/Software_prototyping .. _Dansk: https://da.wikipedia.org/wiki/Unit_test .. _edit: /w/index.php?title=Unit_testing&action=edit§ion=8 .. _edit: /w/index.php?title=Unit_testing&action=edit§ion=9 .. _Articles with short description: /wiki/Category:Articles_with_short_description .. _UP: /wiki/Unified_Process .. _Download as PDF: /w/index.php?title=Special:DownloadAsPdf&page=Unit_testing&action=show-download-screen .. _FDD: /wiki/Feature-driven_development .. _Articles with unsourced statements from January 2013: /wiki/Category:Articles_with_unsourced_statements_from_January_2013 .. _µùѵ£¼Þ¬×: https://ja.wikipedia.org/wiki/%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88 .. _Extreme programming: /wiki/Category:Extreme_programming .. _edit: /w/index.php?title=Unit_testing&action=edit§ion=1 .. _edit: /w/index.php?title=Unit_testing&action=edit§ion=2 .. _edit: /w/index.php?title=Unit_testing&action=edit§ion=3 .. _edit: /w/index.php?title=Unit_testing&action=edit§ion=4 .. _edit: /w/index.php?title=Unit_testing&action=edit§ion=5 .. _edit: /w/index.php?title=Unit_testing&action=edit§ion=6 .. _edit: /w/index.php?title=Unit_testing&action=edit§ion=7 .. _Kolawa, Adam: /wiki/Adam_Kolawa .. _fakes: /wiki/Mock_object#Mocks.2C_fakes.2C_and_stubs .. _Magyar: https://hu.wikipedia.org/wiki/Egys%C3%A9gtesztel%C3%A9s .. _"Alberto Savoia sings the praises of software testing": http://searchsoftwarequality.techtarget.com/originalContent/0,289142,sid92_gci1273161,00.html .. _object-oriented programming: /wiki/Object-oriented_programming .. _Suomi: https://fi.wikipedia.org/wiki/Yksikk%C3%B6testaaminen .. _Use dmy dates from April 2020: /wiki/Category:Use_dmy_dates_from_April_2020 .. _Articles with unsourced statements from November 2008: /wiki/Category:Articles_with_unsourced_statements_from_November_2008 .. _Xojo: /wiki/Xojo .. _About Wikipedia: /wiki/Wikipedia:About .. _nondeterministic: /wiki/Nondeterministic_algorithm .. _assertions: /wiki/Assertion_(software_development) .. _halting problem: /wiki/Halting_problem .. _Software development: /wiki/Software_development .. _Special pages: /wiki/Special:SpecialPages .. _R: /wiki/R_(programming_language) .. _CCO: /wiki/Extreme_programming_practices#Collective_code_ownership .. _978-0-470-04212-0: /wiki/Special:BookSources/978-0-470-04212-0 .. _CD: /wiki/Continuous_delivery .. _Brooks, Frederick J.: /wiki/Fred_Brooks .. _IID: /wiki/Iterative_and_incremental_development .. _TSP: /wiki/Team_software_process .. _Compiler: /wiki/Compiler .. _e: https://en.wikipedia.org/w/index.php?title=Template:Software_development_process&action=edit .. _MSF: /wiki/Microsoft_Solutions_Framework .. _SBE: /wiki/Specification_by_example .. _Kucharski, Marek: /w/index.php?title=Marek_Kucharski&action=edit&redlink=1 .. _ðáÐâÐüÐüð║ð©ð╣: https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5 .. _Fran├ºais: https://fr.wikipedia.org/wiki/Test_unitaire .. _Categories: /wiki/Help:Category .. _Scala: /wiki/Scala_(programming_language) .. _Design: /wiki/Software_design .. _ðæÐèð╗ð│ð░ÐÇÐüð║ð©: https://bg.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%BD%D0%BE_%D1%82%D0%B5%D1%81%D1%82%D0%B2%D0%B0%D0%BD%D0%B5 .. _Mobile view: //en.m.wikipedia.org/w/index.php?title=Unit_testing&mobileaction=toggle_view_mobile .. _Upload file: /wiki/Wikipedia:File_Upload_Wizard .. _JUnit: /wiki/JUnit .. _Waterfall: /wiki/Waterfall_model .. _Extreme programming: /wiki/Extreme_programming .. _Italiano: https://it.wikipedia.org/wiki/Unit_testing .. _threads: /wiki/Thread_(computer_science) .. _test harnesses: /wiki/Test_harness .. _Interlingua: https://ia.wikipedia.org/wiki/Proba_unitari .. _LeSS: /wiki/Scrum_(software_development)#Large-scale_Scrum .. _"RackUnit: Unit Testing": http://docs.racket-lang.org/rackunit/index.html .. _Acceptance testing: /wiki/Acceptance_testing .. _Wikibooks: https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Testing/Unit_Tests .. _All articles needing additional references: /wiki/Category:All_articles_needing_additional_references .. _"The Rust Testing Guide (Rust 0.12.0-pre-nightly)": http://static.rust-lang.org/doc/master/guide-testing.html .. _Wikidata item: https://www.wikidata.org/wiki/Special:EntityPage/Q907375 .. _log: /wiki/Computer_data_logging .. _t: /wiki/Template_talk:Software_development_process .. _Learn how and when to remove this template message: /wiki/Help:Maintenance_template_removal .. _ðíÐÇð┐Ðüð║ð© / srpski: https://sr.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D0%B0%D1%80%D0%BD%D0%BE_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%B0%D1%9A%D0%B5 .. _Release automation: /wiki/Application-release_automation .. _Perl: /wiki/Perl .. _All articles with unsourced statements: /wiki/Category:All_articles_with_unsourced_statements .. _─îe┼ítina: https://cs.wikipedia.org/wiki/Unit_testing .. _CMMI: /wiki/Capability_Maturity_Model_Integration .. _"Getting Started with xUnit.net (desktop)": https://xunit.github.io/docs/getting-started-desktop.html .. _Current events: /wiki/Portal:Current_events .. _Construction: /wiki/Software_construction .. _Regression testing: /wiki/Regression_testing .. _software developers: /wiki/Software_developer .. _Test case: /wiki/Test_case .. _ISO 9001: /wiki/ISO_9001 .. _Wikimedia Foundation, Inc.: //www.wikimediafoundation.org/ .. _adding citations to reliable sources: /wiki/Help:Referencing_for_beginners .. _Documentation: /wiki/Software_documentation .. _Related changes: /wiki/Special:RecentChangesLinked/Unit_testing .. _List of unit testing frameworks: /wiki/List_of_unit_testing_frameworks .. _Profiler: /wiki/Profiling_(computer_programming) .. _Requirements: /wiki/Requirements_analysis .. _refactoring: /wiki/Refactoring .. _RAD: /wiki/Rapid_application_development .. _Clojure: /wiki/Clojure .. _Donate: https://donate.wikimedia.org/wiki/Special:FundraiserRedirector?utm_source=donate&utm_medium=sidebar&utm_campaign=C13_en.wikipedia.org&uselang=en .. _National Instruments: /wiki/National_Instruments .. _control flow: /wiki/Control_flow .. _Articles with unsourced statements from October 2010: /wiki/Category:Articles_with_unsourced_statements_from_October_2010 .. _Design predicates: /wiki/Design_predicates .. _"Agile Emergent Design": https://web.archive.org/web/20120322143534/http://www.agilesherpa.org/agile_coach/engineering_practices/emergent_design/ .. _Artificial intelligence: /wiki/Glossary_of_artificial_intelligence .. _64: https://archive.org/details/mythicalmonth00broo/page/64 .. _PHP: /wiki/PHP .. _TestNG: /wiki/TestNG .. _ASD: /wiki/Adaptive_software_development .. _Permanent link: /w/index.php?title=Unit_testing&oldid=968650276 .. _BABOK: /wiki/A_Guide_to_the_Business_Analysis_Body_of_Knowledge .. _Java: /wiki/Java_(programming_language) .. _Random article: /wiki/Special:Random .. _Articles with example Java code: /wiki/Category:Articles_with_example_Java_code .. _Ýò£ÛÁ¡ýû┤: https://ko.wikipedia.org/wiki/%EC%9C%A0%EB%8B%9B_%ED%85%8C%EC%8A%A4%ED%8A%B8 .. _D: /wiki/D_(programming_language) .. _Lean SD: /wiki/Lean_software_development .. _Stand-up: /wiki/Stand-up_meeting .. _regression test: /wiki/Regression_test .. _needed: /wiki/Wikipedia:NOTRS .. _doi: /wiki/Doi_(identifier) .. _cite: /wiki/Wikipedia:Citing_sources .. _Computer science: /wiki/Glossary_of_computer_science .. _What links here: /wiki/Special:WhatLinksHere/Unit_testing .. _Deutsch: https://de.wikipedia.org/wiki/Modultest .. _ABAP: /wiki/ABAP .. _Recent changes: /wiki/Special:RecentChanges .. _Testing: /wiki/Category:Software_testing_tools .. _Component-based usability testing: /wiki/Component-based_usability_testing .. _OpenUP: /wiki/OpenUP .. _"Theories": https://github.com/junit-team/junit4/wiki/Theories .. _BDD: /wiki/Behavior-driven_development .. _Cite this page: /w/index.php?title=Special:CiteThisPage&page=Unit_testing&id=968650276&wpFormIdentifier=titleform .. _removed: /wiki/Wikipedia:Verifiability#Burden_of_evidence .. _Maintenance: /wiki/Software_maintenance .. _View history: /w/index.php?title=Unit_testing&action=history .. _Privacy policy: https://foundation.wikimedia.org/wiki/Privacy_policy .. _Creative Commons Attribution-ShareAlike License: //en.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License .. _DDD: /wiki/Domain-driven_design .. _Fowler, Martin: /wiki/Martin_Fowler_(software_engineer) .. _automated: /wiki/Test_automation .. _xUnit: /wiki/XUnit .. _Modeling: /wiki/UML_tool .. _"Towards a Framework for Differential Unit Testing of Object-Oriented Programs": http://people.engr.ncsu.edu/txie/publications/ast07-diffut.pdf .. _Read: /wiki/Unit_testing .. _Project management: /wiki/Software_project_management .. _"Change Code Without Fear: Utilize a regression safety net": http://www.ddj.com/development-tools/206105233 .. _Unit Test Frameworks: Tools for High-Quality Software Development: https://books.google.com/books?id=2ksvdhhnWQsC&printsec=frontcover .. _Rust: /wiki/Rust_(programming_language)