Data Retrievals in Unit Tests in TDD
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?
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 Outside-In Test-Driven Development Advanced Unit Testing
What is the best strategy for BDD testing which relies on data
Is it possible to create data driven tests with MSpec?
Testing A Function That Always Returns True
Can xUnit frameworks and BDD work together?
symfony2 tdd developing
TDD is a top-bottom or bottom-top design?
Planning unit tests with TDD
TDD and mocking
testing node.js with expresso - redis session store
Testing interface makes sense?
Is there a workable approach to use Test Driven Development in a COBOL application?
EasyB stories invoked by TestNG?
How long does it take to become easier with TDD? [closed]
MVP with Moq - loading a mocked view
Watch test fails
Requirement Traceability in TDD?