tag:blogger.com,1999:blog-7139179.post7464214914858965064..comments2009-11-22T22:08:38.312+01:00Heinerhttp://www.blogger.com/profile/09520563824611073104noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-7139179.post-85257379888285705482009-11-22T19:39:23.846+01:002009-11-22T19:39:23.846+01:00The tests do not care, what framework you use for them - so that seems to be okay. ;)Allan Wegannoreply@blogger.comtag:blogger.com,1999:blog-7139179.post-25733581934108218462009-11-22T18:58:36.581+01:002009-11-22T18:58:36.581+01:00Yes, thats what I mean. 2 sets of tests. I only want one test mechanism. <br /><br />I prefer integration tests and misuse the integration test framework also for unit tests. In other words: scrap NUnit.Heinerhttp://www.blogger.com/profile/09520563824611073104noreply@blogger.comtag:blogger.com,1999:blog-7139179.post-1587295933844058332009-11-22T18:49:43.112+01:002009-11-22T18:49:43.112+01:00Integration tests are not superior, they are just needed too. Unit tests test single functional units (functions, class methods, and entire modules or classes) of the code.<br />Integration tests are just to complement these and test the cooperation of multiple of that units (an application or more or less large part of it).<br /><br />You most probably always need both!<br /><br />You need unit tests for your libraries and single business code units (modules, classes).<br />And you need integration tests for the applications and logical parts of them.<br /><br />Sure, integration tests may be abused for unit testing too. But then, they magically change name and are called unit tests. ;)<br /><br />Do not bias one over the other - they are eqally usefull.Anonymousnoreply@blogger.com