|
»
« Return to Thread: Automated Method Testing (AMT) Pattern
Re: Automated Method Testing (AMT) Pattern
by Robert Wenner
::
Rate this Message:
On Monday 30 April 2007 06:31, Marvin Toll wrote:
> If you have not been exposed to AMT - I'd appreciate any feedback on
> this definition that values brevity:
>
> http://gtcgroup.com/soaj/Road.to.SOAj.html#AMT
Some comments:
What are hard-coded tests?
What does it mean to author them? Do you mean write?
Why is the volume of test code a challenge? I'd agree it is one if the
compiler chokes on it, but I don't see the connection of size of test
code vs size of production code you seem to imply.
Same for effort -- why do you relate the effort on test code to the effort
on production code? Effort on test code pays back in less defects and
clearer design and other things. Would you also complain about spending
more effort on e.g. design or documentation that on production code?
What is the complexity in launching unit tests? If that is in fact
complex, wouldn't that indicate a flawed build process?
What are patterned objects?
What are unique test maintenance points?
Why is it a good thing if the "need for a shared understanding of
patterned object implementation definitions" (whatever that is) is
increased?
Sure one can reflectively gather all setters and getters and call them.
However, what is really gained from that?
As you write, you may reach higher coverage. Sure, you may even find a
defect. However, I'd be afraid this would lead to a false sense of
security. It's like testing that you can roll the windows in your car up
and down and ignoring the engine.
Also, I cannot imagine how this should work for anything serious.
My tests often involve multiple objects, for example, I may want to set a
Calender object in another object: someObject.setCalender(aCalender).
How do you create meaningful instances of the calender in this case?
How do you automatically create more complex objects where the
constructor may require yet other objects?
What about setters that are not meant to be set easily, e.g., a file name
may only be set before the file is opened?
Also, only few of my objects usually have setters and getters, so I'd not
even bother downloading TestUtil. The getters and setters are certainly
covered in other tests anyway.
Last but not least I don't see why you call this a pattern. It does not
seem to share a lot with patterns as described by Gamma et al -- your AMT
does not even involve code, besides naming conventions?
Sorry, I don't see how this "pattern" is useful at all.
Cheers,
Robert
> If you have not been exposed to AMT - I'd appreciate any feedback on
> this definition that values brevity:
>
> http://gtcgroup.com/soaj/Road.to.SOAj.html#AMT
Some comments:
What are hard-coded tests?
What does it mean to author them? Do you mean write?
Why is the volume of test code a challenge? I'd agree it is one if the
compiler chokes on it, but I don't see the connection of size of test
code vs size of production code you seem to imply.
Same for effort -- why do you relate the effort on test code to the effort
on production code? Effort on test code pays back in less defects and
clearer design and other things. Would you also complain about spending
more effort on e.g. design or documentation that on production code?
What is the complexity in launching unit tests? If that is in fact
complex, wouldn't that indicate a flawed build process?
What are patterned objects?
What are unique test maintenance points?
Why is it a good thing if the "need for a shared understanding of
patterned object implementation definitions" (whatever that is) is
increased?
Sure one can reflectively gather all setters and getters and call them.
However, what is really gained from that?
As you write, you may reach higher coverage. Sure, you may even find a
defect. However, I'd be afraid this would lead to a false sense of
security. It's like testing that you can roll the windows in your car up
and down and ignoring the engine.
Also, I cannot imagine how this should work for anything serious.
My tests often involve multiple objects, for example, I may want to set a
Calender object in another object: someObject.setCalender(aCalender).
How do you create meaningful instances of the calender in this case?
How do you automatically create more complex objects where the
constructor may require yet other objects?
What about setters that are not meant to be set easily, e.g., a file name
may only be set before the file is opened?
Also, only few of my objects usually have setters and getters, so I'd not
even bother downloading TestUtil. The getters and setters are certainly
covered in other tests anyway.
Last but not least I don't see why you call this a pattern. It does not
seem to share a lot with patterns as described by Gamma et al -- your AMT
does not even involve code, besides naming conventions?
Sorry, I don't see how this "pattern" is useful at all.
Cheers,
Robert
« Return to Thread: Automated Method Testing (AMT) Pattern
| Free embeddable forum powered by Nabble | Forum Help |
