'''Data-driven testing''' ('''DDT'''), also known as '''table-driven testing''' or '''parameterized testing''', is a [[software testing]] technique that uses a table of [[data]] tothat directdirects test execution by specifyingencoding input, expected outputsoutput and test-environment settings.<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> TheOne multitudeadvantage of techniquesDDT over forother testing [[software]] co-exist because they differ in the effort required to create and subsequently maintain. One advantage of data-driven testingtechniques is the relative ease to cover an additional [[test case (software)|test case]] for the [[system under test]] by adding a line to a table instead of having to modify test [[source code]].
Often, a table provides a complete set of stimulus input and expected outputs in each row of the table. Stimulus input values typically cover values that correspond to boundary or partition input spaces.
Data-driven testingDDT involves a [[software framework |framework]] that executes tests based on an input tabledata. The framework providesis a [[software reuse |re-usable]] test logicasset tothat can reduce maintenance. Table-drivenof a test [[codebase]]. testingDDT allows for anything that has a potential to change to be segregated from the framework; stored in an external asset. The framework might manage storage of tables and test results in a [[database]] such as [[data pool]], [[Data access object |DAO]] and [[ActiveX Data Objects |ADO]]. An advanced framework might harvest data from a running system using a purpose-built tool (sniffer). The DDT framework can playback harvested data for [[regression testing]].
Automated test suites contain user 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.
==See also==
* [[{{Annotated link |Control table ]]}}▼
* [[{{Annotated link |Keyword-driven testing ]]}}▼
* [[{{Annotated link |Test automation framework ]]}}▼
▲* [[Keyword-driven testing]]
* [[{{Annotated link |Test-driven development ]]}}▼
▲* [[Test automation framework]]
* {{Annotated link |Modularity-driven testing}}
▲* [[Test-driven development]]
* [[Modularity{{Annotated link |Model-drivenbased testing]]}}
* [[Model-based testing]]
==References==
{{Reflist}}
{{refbegin}}
* Carl Nagle: ''Test Automation Frameworks''[httphttps://safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks.htm], Software Automation Framework Support on SourceForge [http://safsdev.sourceforge.net/Default.htm], Data-driven testing approach [https://www.katalon.com/resources-center/tutorials/data-driven-testing/#]{{refend}}
[[Category:Software testing]]
|