A couple of my friends are having the following debate.
-----Original Message----- From: [email protected]]
Sent: 23 August 2006 07:40 To: -- Cc: -- Subject: Re: Unit tests and TDD
This is the way we do it here at ---- :) However, sometimes you need your unit test to "interact" with an object/component that it is not supposed to rely on in determining its result, and that is when you have to start using object mocking.
Not a particularly fun thing to do imho. :)
On 8/23/06, [email protected]> wrote: > It's a cool article. I like the clear way in which he laid out the > challenges. However, I am starting to agree that any unit test which > touches the DB is in fact an integration test, and should be labelled as > such. When developers do their normal builds, only unit tests (in the > strict sense of the word) should be run. You can let CruiseControl run > your unit tests as well as your integration tests. >
From: [email protected]]
Sent: 23 August 2006 10:06 AM To: --- Subject: RE: Unit tests and TDD
I agree, but there are always issues with database unittesting...
What do you think of this article? http://weblogs.asp.net/rosherove/articles/dbunittesting.aspx
From: [email protected]]
Sent: Tuesday, August 22, 2006 5:24 PM To: -- Subject: Unit tests and TDD
Hey,
Here is a really, really interesting article on unit tests. A while ago I wouldn't have agreed with the guy, but now I completely agree.
http://www.artima.com/weblogs/viewpost.jsp?thread=126923
Let me know what you think...
Well.
I think the use of the ADO.NET transaction object in the first article is brilliant! I also think that a distinction should be made between unit tests and integration tests as suggested by the second article.
However, if your database is actually part of your system, i.e. it is shipped with your code and not interchangeable with other database platforms, then I don't believe that tests which perform CRUD operations on the database are integration tests - they are unit tests!
Scenario 1: You are working in a software development team for some firm
You are typically developing software for a very specific technical environment to which your code is tightly integrated, i.e. the firms runs SQL Server 2005 and the database instance contains business logic in stored procedures and meta data in tables that is part of your application - your code is actually shipped with the database into Production!
You would probably find that in this situation your build contains more unit tests than integration tests, because there is a smaller dependency on integration. In this situation the best way to improve your build times won't come from splitting out your integration tests from your unit tests. It would be to break your system up into logical architectural blocks that can be built independently as the system gets bigger. I've seen this work well at a previous financial institution I spent some time at.
Scenario 2: You are working for a software development company that ships a software product
You are typically developing software for an array of different technical environments, i.e. the client runs any one of MySQL, SQL Server or ORACLE and there is or no (or at most very little) business logic in the stored procedures (i.e. the majority of the stored procedures are simple CRUD operations on the tables), and your code ships with the database schema!
In this situation your build will most likely contain a higher percentage of integration tests than unit tests because of the higher dependency on integration. The use of object mocking become more important and by splitting out your integration tests from your unit tests in this scenario I agree will make a huge improvement on your build times!
From the article. I would make the following amendments:
A test is not a unit-test if:
It talks to the database (...that is not shipped with your code and not interchangeable with other database platforms)
It communicates across the network (...that is not shipped with your code and not interchangeable with other network platforms)
It touches the file system (...that is not shipped with your code and not interchangeable with other file system platforms)
.
Recent Comments