Question

I am trying specflow for the first time for a WPF project with MVVM pattern. So, I have repository, controller, view and view model. Repository makes calls to webservice wich hits the database and gives back the data. View model has methods to validate the input from the user and make calls to repository methods.

In my specflow, should I be making a complete call including the repository methods or should I mock those methods using Moq? Does it make sense?

Answer 1

The short answer:
You could make you calls hit the database, but I would recommend mocking them out, unless you have logic in your DB

The long answer:
There’s two competing ways of looking at this question. Firstly what kind of testing are you expecting to use SpecFlow for, and secondly how easy is it going to be to access your database.

If you are using SpecFlow to test your low level technical requirements, then you really are doing unit testing in a Specification by example style. So this really ought to dictate that you use mocking to isolate your units. (Personally I’d stick to using NUnit for these tests.)

If however you are using SpecFlow to test your business scenarios (i.e. Acceptance testing) then your scenarios are reliant on more than one unit to provide the functionality. This is more like Integration or System testing and so many components will need to be involved and in theory since we are testing the whole system, we should include a DB in that, particularly if you have even one stored procedure or view that you might want to regression test later.

However, the second way of looking at this is how much pain is required to have a database available for your testing.

• If there is more than one person in your development team, what strategies would you need to avoid failing if you run your tests at the same time?
  • For example you could generate a new unique customer in each run and only access updates and queries against that customer, then you won’t end up with the wrong number of orders.
• How will you reset your database after your tests run?
  • E.g. If you use the right kind of database you can check an empty .mdb into your source control and just rollback/revert to that.

I’ve personally found that for a simple DB without stored procs and views, mocking is better, but as soon as you’ve added business logic into the DB, well, you need to test that logic somehow.