| org.ddsteps.DDStepsTestCase
All known Subclasses: org.ddsteps.testcase.support.DDStepsExcelTestCase, org.ddsteps.DdTestCase,
| DDStepsTestCase | | abstract public class DDStepsTestCase extends TestCase implements DdBehaviourCallbackHandler(Code) | | DDSteps base class for unit tests that want to controll their own dataloader.
In your test subclass you must implement:
You may implement these hooks if you want to:
author:
adamskogman |
| Constructor Summary | |
| public | DDStepsTestCase()
Standard, no args constructor.
The JUnit contract dictates that if no constructor with a String (name)
argument i sfound, this no-args constructor is used, and then setName()
is called. |
| Method Summary | |
| final public int | countTestCases()
Delegate to behaviour. | | abstract protected DataLoader | createDataLoader()
Factory Method: You as a user of DDSteps must implement this. | | DdBehaviour | getBehaviour()
The appropriate behaviour for this test case instance, given the name. | | final public String | getName()
Returns the full, data driven name, such as testMethod[Rox 13]. | | final public void | run(TestResult result)
Delegate to behaviour. | | final public void | setName(String name)
Overrides setName to handle DDSteps "data driven" names, such as
testMethod[Row 13].
Overriding this method is the only way we can make sure that the name is
always handled correctly.
The name can be either that of the test method (i.e. | | final public void | setUp()
Delegate to behaviour. | | public void | setUpAfterData()
Override this in your subclass, if desired. | | public void | setUpBeforeData()
Override this in your subclass, if desired. | | public void | setUpMethod()
Override this in your subclass, if desired. | | final public void | tearDown()
Delegate to behaviour. | | public void | tearDownAfterData()
Override this in your subclass, if desired. | | public void | tearDownBeforeData()
Override this in your subclass, if desired. | | public void | tearDownMethod()
Override this in your subclass, if desired. | | public String | toString()
Not the same toString as JUnit, instead use a javadoc style syntax. |
| LOG | | static Log LOG(Code) | | Logger
|
| fullName | | String fullName(Code) | | Property: Full, datadriven name of this testcase, i.e. testMethod if a
method instance, or testMethod[Row 13] if a row instance.
The fName in TestCase must not have this string, instead, it will only
ever have the testMethod, as that variable is used in runTest() to
determine what method to run using reflection.
This property is set using (@link #setName(String)) which will set fName
in TestCase to only the method part.
|
| DDStepsTestCase | | public DDStepsTestCase()(Code) | | Standard, no args constructor.
The JUnit contract dictates that if no constructor with a String (name)
argument i sfound, this no-args constructor is used, and then setName()
is called. That is how TestSuite works, anyway, and that's the way we
like it. Our (@link #setName(String)) can then get the behaviour, if
needed.
|
| countTestCases | | final public int countTestCases()(Code) | | Delegate to behaviour.
See Also: junit.framework.TestCase.countTestCases |
| createDataLoader | | abstract protected DataLoader createDataLoader()(Code) | | Factory Method: You as a user of DDSteps must implement this. You should
return the data loader that you want to use to load the test data.
Usually, a DataLoaders would be stateless, so not creating a new instance
every time, but rather using a single instance would make sense. The
stateless dataloaders provided by DDSteps have an easy-to-use INSTANCE
static field, please use that.
It is recommended that you yourself create one (or more) base class for
all your test cases, and implement this method there, as you will
probably use the same kind of data loader for all your DDSteps testcases.
In fact, there are even some utility base classes for you, so that you
don't subclass this class directly.
TODO Add see to util classes
Don't return null.
See Also: org.ddsteps.data.support.DataLoaderFactory.getCachingExcelDataLoader |
| getBehaviour | | DdBehaviour getBehaviour()(Code) | | The appropriate behaviour for this test case instance, given the name.
This method should not be used or overridden, it is strictly internal in
DDSteps.
A behaviour, never null. |
| getName | | final public String getName()(Code) | | Returns the full, data driven name, such as testMethod[Rox 13].
Some tools, especially eclipse, will use this to display and to recreate
the testcase.
See Also: junit.framework.TestCase.getName |
| run | | final public void run(TestResult result)(Code) | | Delegate to behaviour.
See Also: junit.framework.TestCase.run(junit.framework.TestResult) |
| setName | | final public void setName(String name)(Code) | | Overrides setName to handle DDSteps "data driven" names, such as
testMethod[Row 13].
Overriding this method is the only way we can make sure that the name is
always handled correctly.
The name can be either that of the test method (i.e. testFoo), or an
indexed name (i.e. testFoo[Row X]. The contents of the bracket is up to
the DataLoader to interpret, but it indicates that this is a row
instance, not the testMethod instance.
See Also: junit.framework.TestCase.setName(java.lang.String) |
| setUp | | final public void setUp() throws Exception(Code) | | Delegate to behaviour.
See Also: junit.framework.TestCase.setUp |
| tearDown | | final public void tearDown() throws Exception(Code) | | Delegate to behaviour.
See Also: junit.framework.TestCase.tearDown |
|
|