How to do TDD correctly? When do I write tests for layers deeper than my business logic layer (i.e. DAL)?
I'm still not sure how best to use Mocks when developing development externally (for example, first do a write test that simulates client requirements)
Let's say my customer request is "Customer can cancel his order".
I can write a test for this - Test_Customer_Can_Cancel_Her_Order.
Using TDD, I then write a business class and poke fun at the data access layer (or any layer that is "deeper" than my business logic layer). Fantastic, my test is passing and I am only testing the business layer, not all the layers below.
Now I am wondering when I go deeper and start writing and testing the data access layer? Immediately after the top level test? Only when I write an integration test? Maybe it doesn't matter? Until this is done at some point?
Just wondering...
a source to share
It's a difficult question. Some people think it's okay to test "private" code, some people think it's not. This is of course easier, since you don't have to make complex settings to reproduce the state of the application, which allows you to test the small function you want to add (you can test this function directly). I used to be among these people, but now I would say that it is better to just test the public APIs (create tests and settings that only do and see what the user can do and see). The reason for this is that if you only check the public API, you are giving yourself unlimited re-factoring potential. If you test closed source, you will have to change your tests if you decide to refactor (which makes you less prone to "the refactor is merciless "resulting in incorrect code).
However, I must say, testing only public APIs does lead to more complex test environments.
So, to answer your question more accurately, the next step is to try to think about a situation where there is a problem with your current order cancellation code and write a new high-level setting to reproduce the problem. You mentioned data access tests. Create a high level setup where the database is corrupted and check that your application behaves gracefully.
Oh, if for GUI apps this is a bit tricky since you really don't want to get to the point where you check for mouse clicks and read pixels. This is just silly. If you are (and should) use the MVC framework, stop at the controller level.
a source to share
I always write tests to test the DAO level, which does not test business logic, but I find it important to test CRUD functionality. This caused me a lot of problems because if my database gets corrupted for some reason, my tests have a high chance of failing. What I am doing to prevent these DAO type tests from failing is to test on a non-production database first. Then for each CRUD / DAO I test
- find objects that may have been abandoned from a previous test, and if they exist, I delete them.
- I am creating objects that I want to test.
- I am updating the objects I want to test.
- I am clearing or deleting the created objects.
This sequence helps me make sure my database is in a state where my tests don't fail if they run twice, and the first time the test stops halfway between them.
Another way is to wrap your CRUD tests in a transaction and at the end of the test rollback execute the transaction so that the database is in the state it started in.
a source to share