Unit testing - wikipedia Unit testing This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. ( November 2007 ) 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 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 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 Glossaries Artificial intelligence Computer science Electrical and electronics engineering 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 procedures, are tested to determine whether they are fit for use. Contents 1 Description 1.1 Techniques 1.2 Parameterized unit testing 2 Advantages 2.1 Find problems early 2.2 Facilitates change 2.3 Simplifies integration 2.4 Documentation 2.5 Design 3 Limitations and disadvantages 3.1 Decision problem 3.2 Not integration testing 3.3 Combinatorial problem 3.4 Realism 3.5 Record keeping 3.6 Sustainability challenges 3.7 Platform differences 3.8 External work 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 Notes 9 External links Description Intuitively, one can view a unit as the smallest testable part of an application. 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. Unit tests are short code fragments created by programmers or occasionally by white box testers during the development process. It forms the basis for component testing. Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended. Because some classes may have references to other classes, testing a class can frequently spill over into testing another class. A common example of this is classes that depend on a database : in order to test the class, the tester often writes code that interacts with the database. This is a mistake, because a unit test should usually not go outside of its own class boundary, and especially should not cross such process / network boundaries because this can introduce unacceptable performance problems to the unit test - suite. Crossing such unit boundaries turns unit tests into integration tests, and when such test cases fail, it may be unclear which component is causing the failure. Instead, the software developer should create an abstract interface around the database queries, and then implement that interface with their own mock object. By abstracting this necessary attachment from the code ( temporarily reducing the net effective coupling ), the independent unit can be more thoroughly tested than may have been previously achieved. This results in a higher - quality unit that is also more maintainable. Techniques Unit testing is commonly automated, but may still be performed manually. The IEEE does not favor one over the other. The objective in unit testing is to isolate a unit and validate its correctness. A manual approach to unit testing may employ a step - by - step instructional document. However, automation is efficient for achieving this, and enables the many benefits listed in this article. Conversely, if not planned carefully, a careless manual unit test case may execute as an integration test case that involves many software components, and thus preclude the achievement of most if not all of the goals established for unit testing. To fully realize the effect of isolation while using an automated approach, the unit or code body under test is executed within a framework outside of its natural environment. In other words, it is executed outside of the product or calling context for which it was originally created. Testing in such an isolated manner reveals unnecessary dependencies between the code being tested and other units or data spaces in the product. These dependencies can then be eliminated. Using an automation framework, the developer codes criteria, or a test oracle or result that is known to be good, into the test to verify the unit 's correctness. During test case execution, the framework logs tests that fail any criterion. Many frameworks will also automatically flag these failed test cases and report them in a summary. Depending upon the severity of a failure, the framework may halt subsequent testing. As a consequence, unit testing is traditionally a motivator for programmers to create decoupled and cohesive code bodies. This practice promotes healthy habits in software development. Design patterns, unit testing, and refactoring often work together so that the best solution may emerge. Parameterized unit testing Parameterized unit tests ( PUTs ) are tests that take parameters. Unlike traditional unit tests, which are usually closed methods, PUTs take any set of parameters. PUTs have been supported by TestNG, JUnit and various. NET test frameworks. Suitable parameters for the unit tests may be supplied manually or in some cases are automatically generated by the test framework. Testing tools like QuickCheck exist to generate test inputs for PUTs. Advantages The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. A unit test provides a strict, written contract that the piece of code must satisfy. As a result, it affords several benefits. Find problems early 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 may also cause problems for the end - users of the software. Code can be impossible or difficult to 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, it is still early in the development process. Facilitates change 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. Simplifies integration 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. Documentation 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 ). 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. Design 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 behaviour. Limitations and disadvantages Decision problem Testing will not catch every error in the program, because it can not 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 can not 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. Not integration testing 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. Combinatorial problem 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 can not 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. '' Meaning, if two chronometers contradict, how do you know which one is correct ? Realism 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. Record keeping 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. Sustainability challenges It is also essential to implement a sustainable process for ensuring that test case failures are reviewed regularly and addressed immediately. 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. Platform differences 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 can not readily run a test program in the actual deployment environment, as is possible with desktop programs. External work 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. ( December 2016 ) 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 wo n't be as comprehensive as the real database interactions. Example Here is a set of test cases 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 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 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 is n'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 is n'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. 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. Unit testing frameworks See also : List of unit testing frameworks This section needs expansion. You can help by adding to it. ( April 2010 ) 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. Examples of testing frameworks include open source solutions such as the various code - driven testing frameworks known collectively as xUnit, and proprietary / commercial solutions such as Cantata for C / C++ Typemock Isolator.NET/Isolator++, TBrun, JustMock, Parasoft Development Testing ( Jtest, Parasoft C / C + + test, dotTEST ), Testwell CTA++ and VectorCAST / C++. 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. In some frameworks many advanced unit test features are missing or 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 : Apex Cobra Crystal Go LabVIEW MATLAB Python Ruby Rust Some languages without built - in unit - testing support have very good unit testing libraries / frameworks. Those languages include : ABAP C# Clojure Elixir Java JavaScript Obix Objective - C PHP PowerShell Racket Scala tcl Visual Basic. NET See also Software testing portal 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. Notes ^ Jump up to : Kolawa, Adam ; Huizinga, Dorota ( 2007 ). Automated Defect Prevention : Best Practices in Software Management. Wiley - IEEE Computer Society Press. p. 75. ISBN 0 - 470 - 04212 - 5. Jump up ^ Xie, Tao. `` Towards a Framework for Differential Unit Testing of Object - Oriented Programs '' ( PDF ). Retrieved 2012 - 07 - 23. Jump up ^ `` Guide to Agile Practices ''. Archived from the original on 2012 - 04 - 29. Retrieved 2014 - 01 - 06. Jump up ^ `` ISTQB Exam Certification ''. ISTQB Exam Certification. Retrieved 12 March 2015. Jump up ^ Fowler, Martin ( 2007 - 01 - 02 ). `` Mocks are n't Stubs ''. Retrieved 2008 - 04 - 01. Jump up ^ IEEE Standards Board, `` IEEE Standard for Software Unit Testing : An American National Standard, ANSI / IEEE Std 1008 - 1987 '' in IEEE Standards : Software Engineering, Volume Two : Process Standards ; 1999 Edition ; published by The Institute of Electrical and Electronics Engineers, Inc. Software Engineering Technical Committee of the IEEE Computer Society. Jump up ^ 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 May 13, 2016. Jump up ^ `` Test Early and Often ''. Microsoft. Jump up ^ `` Prove It Works : Using the Unit Test Framework for Software Testing and Validation ''. National Instruments. 2017 - 08 - 21. Jump up ^ Cramblitt, Bob ( 2007 - 09 - 20 ). `` Alberto Savoia sings the praises of software testing ''. Retrieved 2007 - 11 - 29. Jump up ^ Brooks, Frederick J. ( 1995 ) ( 1975 ). The Mythical Man - Month. Addison - Wesley. p. 64. ISBN 0 - 201 - 83595 - 9. Jump up ^ Kolawa, Adam ( 2009 - 07 - 01 ). `` Unit Testing Best Practices ''. Retrieved 2012 - 07 - 23. Jump up ^ daVeiga, Nada ( 2008 - 02 - 06 ). `` Change Code Without Fear : Utilize a regression safety net ''. Retrieved 2008 - 02 - 08. Jump up ^ Kucharski, Marek ( 2011 - 11 - 23 ). `` Making Unit Testing Practical for Embedded Development ''. Retrieved 2012 - 05 - 08. Jump up ^ http://wiki.c2.com/?UnitTestsAndDatabases Jump up ^ `` Agile Emergent Design ''. Agile Sherpa. 2010 - 08 - 03. Retrieved 2012 - 05 - 08. Jump up ^ Bullseye Testing Technology ( 2006 -- 2008 ). `` Intermediate Coverage Goals ''. Retrieved 24 March 2009. Jump up ^ `` Crystal Spec ''. crystal-lang.org. Retrieved 18 September 2017. Jump up ^ `` Unit Tests - D Programming Language ''. D Programming Language. D Language Foundation. Retrieved 5 August 2017. Jump up ^ `` testing - The Go Programming Language ''. golang.org. Retrieved 3 December 2013. Jump up ^ Python Documentation ( 2016 ). `` unittest -- Unit testing framework ''. Retrieved 18 April 2016. Jump up ^ `` Minitest ( Ruby 2.0 ) ''. Ruby-Doc.org. Jump up ^ The Rust Project Developers ( 2011 -- 2014 ). `` The Rust Testing Guide ( Rust 0.12. 0 - pre-nightly ) ''. Retrieved 12 August 2014. Jump up ^ Sierra, Stuart. `` API for clojure. test - Clojure v1. 6 ( stable ) ''. Retrieved 11 February 2015. Jump up ^ `` Pester Framework ''. Retrieved 28 January 2016. Jump up ^ Welsh, Noel ; Culpepper, Ryan. `` RackUnit : Unit Testing ''. PLT Design Inc. Retrieved 11 February 2015. External links Test Driven Development ( Ward Cunningham 's Wiki ) Retrieved from `` https://en.wikipedia.org/w/index.php?title=Unit_testing&oldid=840075807 '' Categories : Extreme programming Software testing Unit testing Types of tools used in software development Hidden categories : Articles needing additional references from November 2007 All articles needing additional references Use dmy dates from January 2011 All articles with unsourced statements Articles with unsourced statements from January 2013 Articles with unsourced statements from October 2010 Articles with unsourced statements from January 2010 Articles needing additional references from December 2016 Articles with unsourced statements from November 2008 Articles to be expanded from April 2010 All articles to be expanded Articles using small message boxes Pages using div col without cols and colwidth parameters Articles with example Java code Talk Contents About Wikipedia Tools Wikibooks Български Català Čeština Dansk Deutsch Eesti Español فارسی Français 한국어 Bahasa Indonesia Interlingua Italiano עברית Nederlands 日本 語 Norsk Polski Português Русский Suomi தமிழ் Türkçe Українська Tiếng Việt 中文 18 more Edit links This page was last edited on 7 May 2018, at 15 : 37. 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. About Wikipedia

Question: who is usually responsible for writing unit tests
Answer: software developers