Back to Test Driven Development

Mock the Database Layer

As a test driven development and mock framework advocates you would assume that we would be 100% behind Database Mocking. However we are not dogmatic and believe in using the most appropriate tools for the given situation.

Enterprise v's Small Scale

At the risk of gross generalisation, for large Enterprise environments we frequently find gaining access to the database bureaucratic. Additionally implementing tests even on a Development instance can affect other users. As a result in these scenarios we tend to mock the data layer for unit tests.

For small scale environments were we can clone our own data instance we will typically create unit tests that do not mock the data layer


For further considerations we also have the following pros and cons.

Mocking Pros

  • Speed – Development databases tend to be over loaded and slow for the number of users using them. If your running frequent regression unit tests (as you should) then all those lost milli-seconds can add up to a lot of wasted time.

Mock interfaces should be lightning fast.

  • Negative Testing - your test scenarios can involve negative tests with error returns and destructive tests. This is often easier to implement in a mock framework.

Mocking Cons

  • Time consuming – This is always the challenge for mock tests to justify their existence. While writing mocks does cost time, so do bugs and re-writes due to missed requirements or performance targets.
  • imapacts design - Again a common worry raised against unit testing and mocking. However our experience suggests that the impacts are typically to break the design into smaller more reliable and tested components.
  • It proves nothing – the mock framework may not catch many issues that the real database would. So does the mock provide any value. Our perspective that all testing is incremental. The more and better you test the more you prove. You will probably never prove any code 100%. Strategically applied mock database frameworks can provide a solid first step that ensure subsequent database testing is cost effective and as efficient as possible.

In the End, Its not the Tools

More tools always introduce more choices and sometime increase the complexity. Additional tools should always be critically analysed and not just accepted because the are the new flavour of the month. For us TDD and mocking has increased productivity and reduce risk (and developer stress) your mileage may vary. In the end is up to the developer to make the best choice for themselves.

 
mocking_database_pros_and_cons.txt · Last modified: 2010/01/07 10:04 by root
 
RSS - 200 © CrosswireDigitialMedia Ltd