Darren New wrote:
> Stephen wrote:
>> My understanding of unit testing is that they are just used to test 
>> one aspect of the software, independently. 
> 
> Sure. But if you have one "aspect" that takes a dozen steps to set up, 
> and those steps might fail, do you check each of those previous worked 
> (which means you're testing a bunch of stuff, possibly obscuring what 
> you really want to test), or do you assume they worked because you 
> already tested them (making the tests not independent)?
> 

Are we having a “two countries separated by a common language” moment 
here or is it me speaking fluent “Stephen”? :-)

What you want is to test the components separately under all the 
conditions that you can think of and when you are confident that they 
work you assume that they will work in the end-to-end test (ideally 
written and tested by someone else). If that fails then you start fault 
finding OK trouble shooting ;)
The quality of your unit tests are paramount in proceeding to the next 
step that is the system test.
For instance in SAP, I’ll write a functional spec for a developer to 
write an upload interface and I’ll also write a spec for a functional 
module to take that data and enter it into tables either directly or via 
a standard SAP transaction (which validates the data, somewhat). After 
the developer unit tests the developments separately I’ll rerun the 
tests using my own data including throwing bad data at it. Then I’ll 
join the developments together and see what the output is for all the 
various condition I can think of. Later someone else (the customer) will 
re-run similar tests with different data as an acceptance test.
You often find that an end-to-end test shows up problems that the unit 
tests don’t.
Again I feel I may be speaking fluent “Stephen” :-)



-- 

Best Regards,
	Stephen

Post a reply to this message