Day 2 Session 3: Unit testing with spring
– Testing == good. Making test run fast == good. Automated tests == good
– Dont' use the container in your unit test; that's an integration test. Unit tests should be almost instant and they should not require elaborate setup.
– Mocks are helpful but not a silver bullet.
– Some things can't be sensibly unit–tested: configuration; JDBC code; OR mapping, and (of course) how classes work together. Also need to think about how we test non–java artefacts like DB schemas, config / mapping files, JSPs / other views.
Some stuff isn't worth testing: Hibernate doesn't leak connections and there's no point having a test to prove it. isolate the code that doesn't need testing or can't be tested into DAOs or other similar service objects.
Out–of–container testing is vital – much faster, easier to debug, easier to run individual tests. Spring integration testing is a good alternative. (org.springframework.test, in spring–mock.jar)
Spring integration testing provides context loading / caching, DI, (n.b. AutoWireUtils in spring 2) data access and TX management
Neat tip for TDD: configure the eclipse template for a new method to throw UnsupportedOperationException
Add a comment
You are not allowed to comment on this entry as it has restricted commenting permissions.