Say when testing a database abstraction layer, you instantiate the adapter and inject the provider (mysql, mssql, etc).
Which system is under test? Both? Does mocking the adapter make sense in BDD parlance? Does it make sense to mock either? Because one is the interface, the other the implementation, is it practical to assume they constitute the same system?
System under test = provider
Moderator: General Moderators
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: System under test = provider
If you are unit testing you would test the adapter, and the abstraction class(es), each would be the SUT in their own unit test, each may reappear in the other's unit tests as DOC ( depended on component ) or may be mocked out. you would ideally have tests for your DAO that makes round trips to the database, verifies reads and writes, you'd wrap these kinds of tests in begin transaction / rollback calls so nothing commited.
I made the mistake of making my read tests too humble, that is if I go into the database and edit the record the test will fail of course because the values are no longer equal
1 - clear identity maps to force a fresh read, verify expected values returned ( write tests would be seperate )
I'm having to go back and rewrite some stuff so the flow will basically be like this
1 - begin tranaction
2 - insert expected values, clear identity maps to force a fresh read, verify expected values returned ( this way it is a round trip test )
3 - rollback
The problem with the first approach is it is too brittle towards manual testing interfering with the expected values, the second de-couples the tests from "hard coded" test data, and as long as you call rollback the unit tests wont even interfere with the "production" data
I made the mistake of making my read tests too humble, that is if I go into the database and edit the record the test will fail of course because the values are no longer equal
1 - clear identity maps to force a fresh read, verify expected values returned ( write tests would be seperate )
I'm having to go back and rewrite some stuff so the flow will basically be like this
1 - begin tranaction
2 - insert expected values, clear identity maps to force a fresh read, verify expected values returned ( this way it is a round trip test )
3 - rollback
The problem with the first approach is it is too brittle towards manual testing interfering with the expected values, the second de-couples the tests from "hard coded" test data, and as long as you call rollback the unit tests wont even interfere with the "production" data