-
Declaritive is the proper way, IMO. If youre talking about page .aspx file names, you’re doing it wrong. The purpose of the story is to facilitate communication between developers and non-develoeprs. Non-developers don’t care about products.aspx, they care about a product listing. Your system does something the non-developers find value in. This is what you’re trying to capture.
-
Well, the stories tell the high level features you need to implement. Its what your system must do. The only way to really tell if you’ve done this is to in fact exercise the UI. BDD SpecFlow stories to me don’t replace unit tests, rather they’re you’re integration tests. If you break this, you’ve broken the value the business gets from your software. Unit tests are implementation details your users don’t care about, and they only test each piece in isolation. That can’t tell you if A and B actually work together all the time (in theory it should, in practice interesting [read: unexpected] things happen when you actually have the two parts playing with each other). Automated end to end tests can help with your QA as well. If a functional area breaks, you know about it, and they can spend their time in other areas of the application while you determine what broke the integration tests.
-
This is a tricky one. We’ve done a hybrid approach. We do use the database (integrate tests after all test the system functioning as one thing, rather than the individual components), but rather than resetting configurations all the time we use Deleporter to replace our repositories with Moqs when we need to. Seems to work ok, but there are certainly pros and cons either way. I think we’re still largely figuring this out ourselves.