Data Retrievals in Unit Tests in TDD

StackOverflow https://stackoverflow.com/questions/23283221

  •  09-07-2023
  •  | 
  •  

Question

I have a question about test driven development, which is something I am trying to learn.

I have been reviewing a project delivered by a team of my company to see what kind of stuff they include in their tests.

Basically, for every project in the solution, there is a corresponding test project. This includes the projects in the data layer. I have found that the tests in that project are actually hitting the database and making assertions based on retrieved data.

In fact, the tests of the classes in the Services layer are also hitting the database.

Is this normal in TDD? If not, and if those classes being tested did nothing other than retrieve data, then what would be the best way of testing them? Dare I say, should they be tested at all? If TDD helps drive out the design, arguably they should.

What do the TDD kings out there say?

Was it helpful?

Solution

Is hitting the database from most tests normal in TDD? Yes, unfortunately, it's more normal than it ought to be. That doesn't mean it's right, though.

There are various styles of TDD:

  • Outside-In TDD, popularized by GOOS.
  • Bottom-Up TDD, which is the 'older' style, where you develop 'leaf' components first.

When you use the Outside-In approach, you'd typically start with a few coarse-grained tests to flesh out the behaviour of the system. These might very well hit the a database. That's OK.

However, you can't properly test for basic correctness from the boundary of a complex application alone, because the combinatorial explosion of required test cases is prohibitive. You would literally have to write tens of thousands, or hundreds of thousands of test cases.

Therefore, even with the Outside-In approach, you should write most of the tests at the level of a unit. These tests should not hit the database.

If you're using the Bottom-Up style, you shouldn't hit the database in most cases.

In short, TDD means Test-Driven Development, not necessarily Unit Test-Driven Development, so it may be fine with a few tests hitting a database. However, such tests tend to be slow and fragile, so there should be only a few of them. The concept of the Test Pyramid nicely explains this.

If you want to learn more, you may want to watch my Pluralsight courses

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top