> 2) For any test framework that you use, you may have to modify your own
> class to help testing it ... but this is not bad, this usually brings a
> better design ... For example : let's say you have a class that uses a
> Properties file to read some data. Let's imagine you want to test your class
> that reads it and retrieve some properties. If you want to test all the
> cases, you have to provide several versions of this properties file : some
> with incorrect values, undefined properties, ... It means that even if you
> don't need it, you may have to add a setPropertiesFileName() to your class
> so that when you write your test class you can use the different test
> properties file, ...
But if you have to make setPropertiesFileName public, or to make design
choices for the component based on the testing framework requirements -
no, I don't think that's good. If the component has a
setPropertiesFileName it is because that's the intended behavior.
Unit testing is fine if the framework can test the APIs, it's very bad if
the APIs have to be changed so that the framework can test them. I don't
think the goal is to create components that can be tested by a certain
framework, but to create testing tools that can test the components we
need.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
