I've this confusion all the time. If I write a code which uses fake code to assert some operation, how do i trust my real implementation when it is started really using the real objects instead of fake ones.
For example, I've this code --
[Test]
public void CanCreateContactsWithData()
{
using(ISession session = factory.OpenSession())
using (ITransaction trans = session.BeginTransaction())
{
_contactId = (long) session.Save(contact);
trans.Commit();
}
Assert.AreNotEqual(0, _contactId);
}
This code tests the implementation of a "contact" object whether that gets saved into database or not. If i happened to use a stub instead of a real database connection, do I need to have separate test for storing it in database? And, do you guys call that as integration testing?
Answers are sincerely appreciated.
Martin Fowler has a good discussion here.
From his article:
Meszaros uses the term Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies. (One of his aims was to avoid using any name that was already widely used.) Meszaros then defined four particular kinds of double:
Of these kinds of doubles, only mocks insist upon behavior verification.