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
Recommended thing for a TDD newbie
How to convince a client that all next projects/enhancements should be done via TDD (with some agile practices)?
TDD - How to write test case for a method that as Assembly.LoadFrom(…)
How to practice TDD on a web app?
junit - share a fixture between testcase
How to use TDD correctly to implement a numerical method?
What is Best for Defect Rate Tracking? Defects per KLOC?
TDD with IronPython [closed]
Gallio Icarus vs. Testdriven.net [closed]
Can we come up with a better name for TDD?
TDD in an large project: How do you get started?
How do I get sufficient detail in planning and estimation when using TDD?
What design models to create before TDD?
BDD/TDD: can dependencies be a behavior?
What is the best description of TDD? [closed]
TDD and development time