Fitnesse- Should tests talk to the database?

We are trying to use Fitnesse for our Functional test. Should i be mocking dependencies or should it be testing against the database?

What are the Pros/Cons of either of the approach?开发者_运维知识库

The whole issue of testing against the DB is setting up data which is huge dependency. If we mock then is it real functional test?

Thanks

---

We have a full set of end to end functional tests that run in fitnesse in two modes: "InMemory" and "Database", Depending on which configuration to run the tests in dictates which repositories the tests use. This has several advantages:

1) It keeps the developers from building a lot of functionality into the database and keeps in in the code.

2) When "In-Memory" the fitnesse tests run very very fast. Allowing the tests to fail very very fast...and thus speed up development and agility. When they run in db mode only they do take some time.

---

I see (at least) 2 types of tests that can be done with FitNesse:

• Tests (or examples) intended to specify domain logic or behavior. These I tend not to use with database access as this is usually not important to the purpose of the test.

• End-to-end (or nearly end-to-end) tests used as regression or smoke tests. These, obviously, include database functionality.

The benefit of including the DB is that the test is more representative of the actual production system, the drawback is the additional cost of setting up and managing database state. Look at DbFit, a set of fixtures designed to help with DB set-up and verification.

---

I'd rather isolate the integration tests involving the DB in NUnit. Your fonctional tests should not fail because to integration issues. I've found more comfortable to carry object states through simple singletons than DB.

---

I think it should test against the database. Because as you are doing functional test with fitnesse, you shoudnt be using mock. Use it with database to know the actual database functionality working fine or not as your DB will have a huge data.

---

I have worked on creating a different test suite for DB related stuff which gives me more confidence when I get into other functionality testing. Things like business rules, stored procs and some basic but important tables can be validated to make sure they are where they suppose to be and rendering right results. If that's as expected then what you see on front end should be a solid environment to do functionality tests