- Create a test for a method.
If the code has not been
written and you want to follow a test-first design approach, you must at minimum
define the method signature before generating the test.
- Use the test data table to define simple values for method parameters.
All method parameters and the return value of the method are automatically
identified as inputs or expected outputs in the test data table. Environmental
parameters such as global variables or attributes of the class can also be
considered input or output parameters, but they do not appear automatically
in the test data table. To test these variables and attributes, you can add
initialization points before the call to the method-under-test and add validation
actions after the call to the method-under-test.
- Make sure that the component containing the method-under-test is
in the right state for the test.
If you need to invoke methods
to put your component-under-test in a particular state before you invoke the
method that you are testing, you can add method calls to the test behavior
script.
For example, you might want to test how the pop() method
works on a stack (that is, remove an item from the top of the stack). However,
to be able to remove something, you must first add something to the stack.
Therefore, you often need to invoke some methods to meet the pre-conditions
prior to calling the method-under-test.
- Run the test.
Run the test to make sure that everything
is working properly. If failures are reported, use the Test Data Comparator
to help you understand the test results. If you still do not understand the
results, use the debugger. Keep rerunning the test until it passes.
- Define several data sets using data partitioning techniques.
After you define a test with simple parameter values, it's important
to enhance the test with more data in the domain of possible values. An effective
way to define test values is to perform data partitioning on all of the parameters
that you have identified. Based on this data partitioning, use the test data
table to create as many data sets as you think are necessary.
Also,
you can increase your test coverage by including sets and ranges of values.
However, you must realize that each value defined in a data set is seen as
an individual test, and by increasing the number of individual tests, you
also increase test execution time.
- Rerun the test.
It is possible that there are still
differences between the expected values that you defined and the actual values
that you observed. This may be the result of inappropriate inputs, inappropriate
outputs, or a defect in the component-under-test. To troubleshoot, use the
debugger and the Test Explorer view.
- Assess your test coverage.
To assess your test coverage,
go to the Coverage view in the Profiling perspective and profile the test
that you just defined. If less than 100% of your lines are covered, try expanding
the range of data you are covering, adding some new data sets, or defining
a new test. Details about monitoring code coverage can be found in the online
Help.
To decide what data sets to add, identify the lines of code that
are not covered. Usually those lines are related to decisions in your code,
such as if statements. Very often, because the condition
is always evaluated to false, the block of code following the decision is
not covered. To cover this block of code, identify the right parameter values
and add a data set with these values.