Test-driven development: Difference between revisions

Revision as of 09:46, 25 April 2024

Revision as of 14:24, 3 May 2024

Line 2:

{{Software development process}}

'''Test-driven development''' ('''TDD''') is a way of writing [[source code|code]] that involves writing an [[test automation|automated]] [[unit testing|unit-level]] [[test case]] that fails, then writing just enough code to make the test pass, then [[refactoring]] both the test code and the production code, then repeating with another new test case.

Alternative approaches to writing automated tests is to write all of the production code before starting on the test code or to write all of the test code before starting on the production code. With TDD, both are written together.

Line 20:

}}

== Test-driven developmentCoding cycle ==

[[File:TDD Global Lifecycle.png|thumb|A graphical representation of the test-driven development lifecycle]]

The TDD steps vary somewhat by author in count and description, but are generally as follows. These are based on the book ''Test-Driven Development by Example'',<ref name=Beck>{{cite book |last=Beck| first=Kent |title=Test-Driven Development by Example |publisher=Addison Wesley |___location=Vaseem |date=2002-11-08 |isbn=978-0-321-14653-3}}</ref> and Kent Beck's [https://tidyfirst.substack.com/p/canon-tdd Canon TDD article].

;1. List the test scenarios for the new feature

:List the expected variants in the new behavior. “There’s the basic case & then what-if this service times out & what-if the key isn’t in the database yet &…” The developer can discover these specifications by asking about [[use case]]s and [[user story|user stories]]. A key benefit of TDD is that it makes the developer focus on requirements ''before'' writing code. This is in contrast with the usual practice, where unit tests are only written ''after'' code.

;2. AddWrite onea test fromfor an item on the list

:Write an automated test that ''would'' pass if the variant in the new behavior is met.

;3. Run all tests. The new test should ''fail'' {{endash}} for ''expected'' reasons

Line 69:

===Code visibility===

[[Test suite]] code clearly has to be able toneeds access the code it is testing., Onbut thetesting othershould hand,not compromise normal design criteriagoals such as [[information hiding]], encapsulation and the [[separation of concerns]] should not be compromised. Therefore, unit test code for TDD is usually writtenlocated withinin the same project or [[Module (programming)|module]] as the code being tested.

In [[object oriented design]] this still does not provide access to private data and methods. Therefore, extra work may be necessary for unit tests. In [[Java (programming language)|Java]] and other languages, a developer can use [[Reflection (computer science)|reflection]] to access private fields and methods.<ref>{{cite web