Data-driven testing: Difference between revisions

Revision as of 23:12, 7 August 2025

Revision as of 23:25, 7 August 2025

Line 1:

'''Data-driven testing''' ('''DDT'''), also known as '''table-driven testing''' or '''parameterized testing''', is a [[software testing]] technique that is used in the testing of [[computer]] [[software]] to describe testing done using a table of conditions directly as test inputs and verifiable outputs as well as the process where test environment settings and control are not hard-coded.<ref>{{cite web |title=golang/go TableDrivenTests |url=https://github.com/golang/go/wiki/TableDrivenTests |website=GitHub |language=en}}</ref><ref>{{cite web |title=JUnit 5 User Guide |url=https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests |website=junit.org}}</ref> In the simplest, form the tester supplies the inputs from a row in the table and expects the outputs which occur in the same row. The table typically contains values which correspond to boundary or partition input spaces.

Many techniques are available for testing [[software]]. They co-exist because they differ in the effort required to create and subsequently maintain. The advantage of data-driven testing is the ease to add additional inputs to the table when new partitions are discovered or added to the product or [[system under test]]. Also, in the data-driven testing process, the test environment settings and control are not hard-coded. The cost aspect makes DDT cheap for automation but expensive for manual testing.

==Overview==

Data-driven testing isinvolves thea creationframework ofthat testexecutes scriptstests tobased runon togetheran withinput their related data sets in a frameworktable. The framework provides re-usable test logic to reduce maintenance and improve test coverage. Input and result (test criteria) data values can be stored in onecentralized or more central data sourcesstorage or [[database]]s, the actual format, organization and tools can be implementation specific.

TheOften, dataa comprisestable variablesprovides useda forcomplete bothset inputof valuesstimulus input and outputexpected verificationoutputs in each row of the table. Stinulus input values typically cover values that correspond to boundary or partition input spaces. In advanced (mature)testing automation environmentssystems, data can be harvested from a running system using a purpose-built custom tool or (sniffer,). theThe DDT framework thus performscan playback of harvested data; producing a powerful automated regression testing tool.

Automated test suites contain user's interactions through the system's GUI, for repeatable testing. Each test begins with a copy of the "before" image reference database. The "user interactions" are replayed through the "new" GUI version and result in the "post test" database. The ''reference'' "post test" database is compared to the "post test" database, using a tool.<ref>{{cite web |url=http://www.diffkit.org/ |title=Home |website=diffkit.org}}</ref> Differences reveal probable regression. Navigation the [[System Under Test]] user interface, reading data sources, and logging test findings may be coded in the table.

Navigation through the [[System Under Test|program]], reading of the data sources, and logging of test status and information are all coded in the test script.

==Data driven==