CODEWITHSUNDEEP
unit-testingjunittdd
mike rodent
mike rodent

Reputation: 15652

TDD - what's the approach with this sort of dependent sequence situation?

I'm currently getting to grips with Lucene indexing, and scratching my head about the "correct" approach if using TDD.

To do this you have to create an IndexWriter, produce an index based on a simple collection of texts (Strings), which are tokenized, stemmed, etc.

To look up a query in this index you have to create a DirectoryReader, make a Query, get the hits, etc.

So in the course of making my first test class (JUnit 4) I did each of these steps, one by one, making a new test method for each step in this process which ultimately produces a non-zero number of hits, if all goes well.

The problem I have is that the last test method does ALL these steps: clears the index directory, creates an IndexWriter, makes the index, etc. etc. and finally counts the hits. This last method can ultimately be tripped up by anything along the way going wrong. Furthermore, the previous methods all seem redundant...! And no "mocking" opportunities seem to present themselves...

Is this a candidate for a "test suite"? How does a TDD Pro develop "appropriate" testing for a situation like this?

Upvotes: 1

Views: 51

Answers (1)

TheEllis
TheEllis

Reputation: 1736

It sounds to me that the last test method you refer to is more of an integration test than a unit test. Unit tests should only test a very specific unit of code (usually a method or part of a method) and should mock out any interactions with other classes, shouldn't touch a database, filesystem, or anything outside of the specific unit of code under test. It sounds like the first tests you created are unit tests and last test is an integration test. It's ok to have some redundency between the two types of tests since the unit test are testing very specific pieces of logic and integration testing test the interaction between those pieces.

Upvotes: 1

Related Questions