{"id":5003453,"date":"2015-12-17T01:03:37","date_gmt":"2015-12-17T09:03:37","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&p=5003453"},"modified":"2022-08-30T12:12:15","modified_gmt":"2022-08-30T19:12:15","slug":"unit-test","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/unit-test\/","title":{"rendered":"Unit Testing"},"content":{"rendered":"
\n
\n

A unit test, as Agile teams understand the term, is a short program fragment written and maintained by the developers on the product team, which exercises some narrow part of the product\u2019s source code and checks the results. The outcome of a unit test is binary: either \u201cpass\u201d if the program\u2019s behavior is consistent with the recorded expectations, or \u201cfail\u201d otherwise. Developers will typically write a large number of unit tests (corresponding to a large number of program behaviors of interest), called a \u201ctest suite\u201d. By common convention dating back at least to the\u00a0JUnit<\/a> family of tools, the color red (as in \u201cgetting a red bar\u201d) represents the failure of one or more tests. The color green (\u201ca green bar\u201d) denotes the successful execution of \u201call\u201d unit tests associated with a program.<\/p>\n

Also Known As<\/h2>\n

The term Unit Testing has a different meaning in the industry, denoting an activity or phase in the classical Software Development Life Cycle, which distinguishes it from (for instance) System Testing. These terms do not necessarily imply anything about automation. To avoid creating confusion, some Agile authors have therefore advocated using the term \u201cdeveloper testing\u201d, distinguishing it from \u201ccustomer testing\u201d and emphasizing the roles responsible for various types of testing.<\/p>\n

Common Pitfalls<\/h2>\n

The shifts in terminology noted above have been the source of much confusion, and debate continues over what \u201ctesting\u201d means in Agile teams. Agile has led to a strong emphasis, among developers, on the use of automated checking procedures, and this has tended to marginalize other forms of testing, in particular, that done by professional testers. Yet this work (which some Agile teams call \u201cexploratory<\/a>\u201d testing) is no less important in an Agile context. Also keep in mind the distinction between the practice of automated unit testing, used by developers to check their own code, and the more structured and more constraining practice of\u00a0test-driven development<\/a>.<\/p>\n

Expected Benefits<\/h2>\n