Data-driven testing: Difference between revisions

Revision as of 14:54, 28 July 2009

Latest revision as of 11:36, 16 August 2025

(70 intermediate revisions by 50 users not shown)

Line 1:

'''Data-driven testing''' (DDT), also known as '''table-driven testing''' or '''parameterized testing''', is a [[software testing]] technique that uses a table of [[data]] that directs test execution by encoding input, expected output 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> One advantage of DDT over other testing techniques is 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]].

{{context}}

{{Portal|Software Testing}}

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 testing is a term used in the testing of [[software]]. The idea is to lower maintenance and improve coverage by using re-usable test logic. When you first author any test, it has all sorts of hard cording of environment, end points, test data, locations, etc. Everything that has a potential to change (also called "Variability") must be separated from the test logic and moved into an external asset, which can be a configuration or test data. You can then add more data or change the configuration to reuse the same test logic and run through multiple data scenarios.

DDT involves a [[software framework |framework]] that executes tests based on input data. The framework is a [[software reuse |re-usable]] test asset that can reduce maintenance of a test [[codebase]]. DDT 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]].

==Introduction==

In the testing of [[Computer software|software]] or [[Computer program|programs]], several methodologies exist in dictating how this testing will be performed. Each of these methods exist because they differ in their effort required to establish initially and then to subsequently maintain. This article aims to explain the data-driven method which is part of the [[Test automation|automated testing]] disciplines.

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.

==Methodology Overview==

'''Data-driven testing''' is a methodology used in [[Test automation]] where [[test script]]s are executed and verified based on the data values stored in one or more central data sources or [[database]]s. These databases can range from datapools, [[Open Database Connectivity|ODBC]] sources, [[Comma-separated values|csv files]], [[Microsoft Office Excel|Excel]] files, [[Data Access Object|DAO]] objects, [[ActiveX Data Objects|ADO]] objects, etc. Data-driven testing is the establishment of several interacting test scripts together with their related data results in a framework used for the methodology. In this framework, variables are used for both input values and output verification values: 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. Thus, the logic executed in the script is also dependent on the data values.

This is similar to [[Keyword-driven testing]] inis similar except that the logic for the test case itself is containedencoded as data values in the dataform valuesof a set of "action words", and not embedded or "hard-coded" in the test script;. theThe script is justsimply a "driver" (or delivery mechanism) for the data. Unlike in keyword-driven testing, though, the navigation data isn't contained in the test script. In data-driven testing, only test datathat is containedheld in the data source.

==See also==

* {{Annotated link |Control table}}

* [[{{Annotated link |Keyword-driven testing]]}}

* [[Test Automation Framework]]

* {{Annotated link |Test automation framework}}

* [[Test-Driven Development]]

* {{Annotated link |Test-driven development}}

* [[Hybrid Automation Framework]]

* {{Annotated link |Modularity-driven testing}}

* Data Driven Testing

* {{Annotated link |Model-based testing}}

* Meta Data Driven Testing

* Modularity-driven testing

* Hybrid testing

* Model-based testing

==References==

{{reflistReflist}}

{{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}}

{{refend}}

[[Category:Software testing]]