Unit Testing and Integration Testing in real projects

I am yet to find a proper sample on how to do realistic Test
Driven Development (TDD) and how to write proper unit tests for
complex business applications, that gives you enough confidence to
stop doing manual tests anymore. Generally
the samples
show you how to test a Stack or a LinkedList, which
is far simpler than testing a typical N-tier application,
especially if you are using Entity Framework or Linq to SQL or some
ORM in data access layer, and doing logging, validation, caching,
error handling at middle tier. There are many
, blog
, video tutorials on
how to write unit tests, which I believe are all very good starting
points. But all these examples show you basic tests, not good
enough to let your QA team go. So, let me try to show you some
realistic unit and integration test examples which should help you
write tests that gives you confidence and helps you gradually move
towards TDD.

I will show you tests done on my open source project Dropthings, which is a Web
2.0 AJAX portal built using jQuery, ASP.NET 3.5, Linq to SQL,
Dependency Injection using Unity, caching using Microsoft
Enterprise Library, Velocity and so on. Basically all the hot techs
you can grasp in one shot. The project is a typical N-tier
application where there’s a web layer, a business layer and a
data access layer. Writing unit tests, integration tests and load
tests for this project was challenging, and thus interesting to
share so that you can see how you can implement Unit Testing and
Integration Testing in a real project and gradually get into Test
Driven Development.


Read this codeproject article of mine to learn how I did
Integration Tests and Unit Tests using Behavior Driven Development

Unit Testing and Integration Testing in business


If you like it, please vote for me.

3 thoughts on “Unit Testing and Integration Testing in real projects”

  1. I'd suspect that one of the reasons you don't find any examples of TDD for complex business application or n-tier applications is because unit tests aren't written for the entirety of the application. A unit test, written in the context of TDD is only written for a small segment of code, in isolation. Not across layers, concerns, or boundaries within the code base. At that point one has to have QA/Integration Testing step in. TDD is not setup, nor designed, nor intended for multi-step, complex, n0tier business applications. Instead it is for the discrete and minute details of the application.

    Just sayin'. 🙂

    btw – Love your blog, been reading ever since I fussed about WCF REST, and though “hey, someone ought to just do it in ASP.NET MVC”. Which then I figured I Google it and found your blog. Good stuff!

Leave a Reply