The context is the following we have an MVC web application with a lot of legacy code in the database. (We are not allowed to migrate this code to the server side)
For our persistance store we use the Repository pattern.
Our client want to add new features to the application so we obviously added all the new business logic on the server side.
The problem we have now is regarding our functional test suite which is running slower and slower every days.
The main reason is that we are running tests from the browser using selenium to the database (End to end).
I’d like to know if people have been successfull using the following other strategies:
1. Get rid of the UI
Running the tests at the Controller level instead of having to have to go through the browser and web server. To compensate the lost of testing through the UI we would write javascript unit tests or MVC Views unit tests.
2. Get rid of the DB
Write an “InMemory” version of our repository so that the application can run completely in memory, that should speed up the Test suite too, since we wont hit the disk and less networking. To compensate we would write integration tests for our Database Repositories.
I think that doing both 1+2 strategies would yield maximum speed execution and we will test the stuff that really matter (controllers,business layer, domain entities and various helpers as an integrated whole) (I consider, UI and the DB as “details”).
Now, the problem is that in fact since the DB has a lot of legacy code, I don’t know if it’s safe enought to just rely on integration tests for that stuff and keeping the DB out of the functionnal test suite. Should I leave it in the suite anyway ? Or is it fine ?
Any experience or suggestion would be greatly appreciated !
Some of my findings are the following:
- The Continuous delivery book suggest that these test should always be end to end even if they are slow (althought they also say that not everybody would agree on that)
- Uncle bob would, in my understanding, agree on the 1+2 strategy, but I’m not sure if he would think that with a database with legacy code.
The growing duration of the tests is the primary concern. Eventually it will grow to a point where you’ll have to abandon some of the tests. That’s a slippery slope.
To forestall that, I would certainly adopt 1+2 strategy, but I would also maintain a certain amount of end-to-end testing.
As you add more and more tests that bypass the UI and DB, you can start deciding which end-to-end tests are redundant, and which are necessary in order to test that the system is connected properly.
The goal, in the end, if for end-to-end tests to be purely plumbing tests, with all business rules and presentation behaviors tested using the 1+2 strategy.
Your stored procedures are a complication. So long as you aren’t more features to the database code, you can probably manage it. In fact, if you can gradually replace some of that database code with server code you’ll be better off. Some of the database code can be tested without the rest of the system present. And some of the database behavior can be mocked. Unfortunately there are also probably behaviors that can only be tested end-to-end, and so you’ll likely have to keep those tests in place for as long as that legacy database code exists.
The most important factor here is to take things slowly, and avoid backsliding. Don’t embark upon a huge project to “fix the tests”. Make gradual incremental improvements instead. Practice “The Boy Scout Rule”, always leave the tests better than you found them. Never make them worse. Bit by bit, move more and more tests into strategy 1+2. Bit by bit replace those stored procedures that you feel comfortable replacing. Gradually eliminate the most redundant end-to-end tests.