Data Driven Test Cases using Excel - Documentation

Under construction. Heavily!

Introduction

DDSteps makes it possible to write data driven test cases in many ways, but the first and most important is using Excel.

DDSteps is essentially JUnit with a data driven extension, so most of what is true in JUnit is true when using DDSteps. Many terms are used in different ways by different people, so let me explain what I mean by:

Term	Definition
Test Class	Your Java class in which you code your tests. A subclass of org.junit.TestCase or when you use DDSteps a subclass of org.ddsteps.DdTestCase or some of our utility classes. Contains one or many test methods.
Test Method	A method in a test class. Since this is JUnit, test methods are named `testSomething`.
Test	When used unqualified, it usually means one test, i.e. a test method.
Test Case	Very amiguous, since the JUnit base class is called TestCase, which contains more than one test [[method]]. When used in an abstract fashion, it often means a test, i.e. test method really. When used in this text, it mostly refers to a Test Class.

Unit Tests

When unit testing, you want to use pretty standard JUnit tests - no Spring stuff, no databases and so on. But you probably still want to run the same test method more than once, using different data. DDSteps is all about parameterizing your tests.

The easiest way - `DDStepsExcelTestCase`

The easiest way is simply to let yoru test class extend org.ddsteps.testcase.support.DDStepsExcelTestCase. This is a nice support class introduced in DDSteps 1.1.

import org.ddsteps.testcase.support.DDStepsExcelTestCase;

public class MyTest extends DDStepsExcelTestCase {
...
}

Voila! If you put an Excel file in the same package as your test class, and name it like your test class, e.g. MyTest.xls, you are now data driven. Remember - name the sheet like your test method, e.g. testSomehing, no () at the end though. If there is no sheet for a test method, it will run the test method once (just like JUnit does).

To get your Excel file started right, use the template that is included in the binary distribution, or look at the Excel Template page. See Excel Test Data Format for full details on how the Excel file should look.

Property Placeholders (added by default)

In the test data in the Excel sheet, you can write these nice property placeholders: *${foo.bar}. They are very convenient for making test data dependent on the current user (use ${user.name} or for placing the current time and date in your test case. Long story short: the key, foo.bar, is looked up first as a system property, then in the file ddsteps-placeholders.properties in the root of your classpath.

For more information, see Property Placeholders.

Default data from `ddsteps-defaults.properties` (added by default)

Sometimes you want some piece of data in every test case in your entite suite of tests. Then just put it in the file ddsteps-defaults.properties. The keys in this file are standard property headers, just like the ones you put in the Excel file:

hostname=my.host.com

Using a Different Data Loader

In DDSteps 1.1 there is only one way of getting data in, and that is Excel. Now, if you want to write your own DataLoader to pull in data from somewhere else, you are very welcome to do so. In that case you want to use a different DDSteps base class:

org.ddsteps.testcase.support.DDStepsTestCase (in DDStesp 1.1)
org.ddsteps.DdTestCase (in DDSteps 1.0)

No matter which you choose of the above base classes, you must implement a factory method: createDataLoader().

import org.ddsteps.testcase.support.DDStepsTestCase;

public class MyAbstractTestCase extends DDStepsTestCase {

	protected DataLoader createDataLoader() {
		return ...your DataLoader here...
	}

}

Using Spring

If you want to use Spring - typically to du integration or function testing - read [Data Driven Test Cases using Excel and Spring].