If you’ve never done Test Driven Development or aren’t even sure what this "crazy TDD stuff” is all about than this is the series for you. Over the next 30 days this series of posts take you from “I can spell TDD” to being able to consider yourself a “functional” TDD developer. Of course TDD is a very deep topic and truly mastering it will take quite a bit of time, but the rewards are well worth it. Along the way I’ll be showing you how tools like JustCode and JustMock can help you in your practice of TDD.
Previous Posts in this Series: 30 Days of TDD – Day 25 – Reader Question #1
Emad Mokhtar asks
I want to know how to test my business logic which is basically related to database, I know dealing with database is integration test not unit test but this is what I want to take care of, weather my Employee entity inserted or not, did my validation work or not, what if I insert Employee and failed when in inserting his/her addresses, and can I connected to database.
Thanks for the question Emad.
You already understand the difference between a unit test and an integration test, so the solution is actually pretty simple; use NUnit to write an integration test. I do this all the time. Integration tests are import parts of a testing suite, and there’s no reason you can’t write them with NUnit.
Your approach will be a little different; you won’t worry about mocking and you’ll probably want to use a DI framework to build out your stack. The first thing you should do is run a query or make sure your database is in a “starting position” meaning your tables are ready to receive your new entity. Then create the entity in your unit test and (attempt to) save it to your database. Once that action is complete you’ll need to query your database again (via whatever data access layer you are using in your application) to see if your entity was properly saved. If it was, your test passes.
As you can imagine this test is going to take quite a bit longer to run than a normal unit test. Because of this I like to keep my integration test and my unit tests in separate projects so that I can control which get run.
Continue the TDD journey: