tag:blogger.com,1999:blog-6628985022531866193.post3452395738357162997..comments2024-02-12T17:37:05.629+00:00Comments on The OldWood Thing: Integration Testing with NUnitChris Oldwoodhttp://www.blogger.com/profile/18183909440298909448noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-6628985022531866193.post-56355979852286737752010-09-22T08:52:14.999+01:002010-09-22T08:52:14.999+01:00Thanks for your reply.
I'm following the same...Thanks for your reply.<br /><br />I'm following the same design with data that is only ever read (not modified or deleted) being dealt with in the fixture setup/teardown etc. and data that is manipulated being dealt with in the the test setup/teardown, or the test itself.<br /><br />It hasn't felt overly burdensome so far.<br /><br />Thanks,<br />Geoff.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6628985022531866193.post-41183508264592104852010-09-03T14:09:02.283+01:002010-09-03T14:09:02.283+01:00I definitely stick to the unit test philosophy of ...I definitely stick to the unit test philosophy of making all tests independent as I've been bitten before with tests that rely on ordering creating other issues.<br /><br />The main side-effect I see is the increase in runtime as you need to keep recreating your test data (files, rows etc) before each test and cleaning up afterwards.<br /><br />For the database scenario where you often need to insert quite a few rows to satisfy foreign key constraints I use helper classes to manage the common code needed by different test fixtures. I tend to insert/delete 'static data' such as customers and currencies in the fixture setup/teardown and manage more specific test data in the per-test setup/teardown to keep the runtime down.<br /><br />My main aim when integration testing a DAL is really just verifying sproc names, parameter names and their data types in the code to ensure correctness and fidelity. I have separate SQL unit tests to verify their behaviour so I haven't run into any real dependency issues. Plus the integration test db is built and owned by me so I can use raw inserts and deletes etc to manipulate the db outside the normal 'public interface'.Chris Oldwoodhttps://www.blogger.com/profile/18183909440298909448noreply@blogger.comtag:blogger.com,1999:blog-6628985022531866193.post-16607062039998260822010-08-27T01:09:24.248+01:002010-08-27T01:09:24.248+01:00Hello Chris,
When writing integration tests do yo...Hello Chris,<br /><br />When writing integration tests do you stick to the unit testing rule that all test should be independent?<br /><br />Using NUnit, you have to either do this, or combine the dependent tests within a single test method, unless you pick your test names so they run alphabetically by design.<br /><br />When testing a data access layer that uses a database, I find this makes writing integration tests harder as you have to prepare more test data. For example you can't just rely on a data created by one test for use in another test.<br /><br />Grouping dependent tests inside one test method solves this, but makes it marginally harder to see straight away where the problem is when test fail.<br /><br />I'd be interested to know which way do you handle this situation.<br /><br />Thanks,<br />Geoff.Anonymousnoreply@blogger.com