Home » Language IDEs » Java Development Tools (JDT) » Advice on JUnit testing approach
| Advice on JUnit testing approach [message #72544] |
Thu, 03 July 2003 21:38  |
 Matthew King
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
I have a class with fairly complex behavior for which I am designing a
JUnit testing strategy. I am green with JUnit, and I am wondering if the
testing approach I am taking is sensible.
The class to be tested, TweakableURL, has methods for URL string
manipulation and also has a sequence of predefined forms through which a
string, which is potentially a valid URL, can be morfed. For example, an
URL segment which is an ISO country code can be moved or substituted with
a country code wild card: www.ibm.com.uk could be morfed to www.ibm.com/uk
or www.ibm.com.<cc> or www.ibm.com/<cc>.
For completeness, it is necessary to test all the get methods of the class
after each "morfing". Thus, for instance, we need a sequence like:
1. test url.toString()
2. test url.getProtocol()
3. Morf with url.setNextForm()
4. test url.toString() for the new form
5. test url.getProtocol() for the new form
6. Morf again ...
7. test again ...
....
In the above sequence of tests, most of the get method tests (like
getProtocol()) "should", but may not, return the same value after each
morfing whereas the toString test and get method requesting the current
form descriptor will return something different after each morfing.
To make generating the expected values for the test cases reasonably
practical, I have defined them in properties files. So, each TweakableURL
instance has its own properties file. That allows me to create a template
file that is easy to fill out. For example:
url=www.ibm.com.uk
protocol=
server=www.ibm.com.uk
....
form1=www.ibm.com/uk
form2=...
....
Now the hard part ... well, it's easy but I'm not sure it is the best match
to the Eclipse implementation of the framework.
Since each test method in a TestCase instance is executed just once, it
did not seem to make sense to create a test method for each getter.
Instead, I have one public testForms method that:
for (each TwekableURL url)
{
for (each url.setNextForm())
{
testGettersForURL(url);
}
}
The testGetters method makes assertions for each property loaded into an
expected values properties object for that url.
So, all the assert calls are essentially made by a single test method.
That didn't seem like a very transparent use of the framework. But, every
other approach I've conceived involved a significant amount of duplicate
code, or at least a lot more coding or greater difficulty maintaining the
expected value data.
I hope this is clear enough to allow for constructive criticism.
Thanks,
--
Matt King
|
|
|
| Re: Advice on JUnit testing approach [message #74008 is a reply to message #72544] |
Tue, 08 July 2003 13:58  |
Eclipse User |
|
|
|
Originally posted by: bob.news.gmx.net
"Matt King" <mattking@us.ibm.com> schrieb im Newsbeitrag
news:Xns93AD9F06568Cmattkingusibmcom@204.138.98.10...
> I have a class with fairly complex behavior for which I am designing a
> JUnit testing strategy. I am green with JUnit, and I am wondering if
the
> testing approach I am taking is sensible.
>
> The class to be tested, TweakableURL, has methods for URL string
> manipulation and also has a sequence of predefined forms through which a
> string, which is potentially a valid URL, can be morfed. For example,
an
> URL segment which is an ISO country code can be moved or substituted
with
> a country code wild card: www.ibm.com.uk could be morfed to
www.ibm.com/uk
> or www.ibm.com.<cc> or www.ibm.com/<cc>.
>
> For completeness, it is necessary to test all the get methods of the
class
> after each "morfing". Thus, for instance, we need a sequence like:
>
> 1. test url.toString()
> 2. test url.getProtocol()
> 3. Morf with url.setNextForm()
> 4. test url.toString() for the new form
> 5. test url.getProtocol() for the new form
> 6. Morf again ...
> 7. test again ...
> ...
>
> In the above sequence of tests, most of the get method tests (like
> getProtocol()) "should", but may not, return the same value after each
> morfing whereas the toString test and get method requesting the current
> form descriptor will return something different after each morfing.
>
> To make generating the expected values for the test cases reasonably
> practical, I have defined them in properties files. So, each
TweakableURL
> instance has its own properties file. That allows me to create a
template
> file that is easy to fill out. For example:
>
> url=www.ibm.com.uk
> protocol=
> server=www.ibm.com.uk
> ...
> form1=www.ibm.com/uk
> form2=...
> ...
>
> Now the hard part ... well, it's easy but I'm not sure it is the best
match
> to the Eclipse implementation of the framework.
>
> Since each test method in a TestCase instance is executed just once, it
> did not seem to make sense to create a test method for each getter.
> Instead, I have one public testForms method that:
>
> for (each TwekableURL url)
> {
> for (each url.setNextForm())
> {
> testGettersForURL(url);
> }
> }
>
> The testGetters method makes assertions for each property loaded into an
> expected values properties object for that url.
>
> So, all the assert calls are essentially made by a single test method.
> That didn't seem like a very transparent use of the framework. But,
every
> other approach I've conceived involved a significant amount of duplicate
> code, or at least a lot more coding or greater difficulty maintaining
the
> expected value data.
>
> I hope this is clear enough to allow for constructive criticism.
Hm, can't you isolate certain single behavior (eg. a special morphing
step) and create a test method for each behavior? You could still reuse
the single private "test and assert" method but you would have a set of
public "testBehaviorXYZ" methods that would give you a bit better error
feedback.
robert
|
|
|
Goto Forum:
Current Time: Sat Jul 20 23:24:37 GMT 2024
Powered by FUDForum. Page generated in 0.02933 seconds |
] 
Search
Help
Register
Login
Home
