Testing crap in web applications like ASP.NET MVC
Rob Ashton. What a presenter! I attended his session on Javascript last year and this session finished the day with a BOOM!
His talk nicely followed on from Ian's earlier talk. He focused on talking about testing an MVC application from the outside in. What does that mean? Simply put, UI test pretty much everything. Only unit test complex domain logic or validation rules but everything else should be tested as a feature through the UI. The UI? But that is going to be slow and lacking in granularity? What about feedback when my tests fail so I know where they have failed? These are all questions which Rob answered in a very convincing manner.
Slow - "If your application is so slow that it is not practical to test via the UI then there is a problem with your application. You have a defect that needs to be fixed right there - Make your application faster". Rob cut to the chase when answering this but is this attainable is all scenarios? Yes, we should be writing web applications that are fast as possible for a good user experience but does that extend to being able to execute 100's of UI tests against it in seconds..?
Persistence - He discussed the use of in memory data stores or in memory representations for relational databases (NHibernate and RavenDB support this. Not sure about EF) when running tests locally and for CI. These implementations can be swapped out for a real relational database when moving to QA. He also discussed using persistence technologies like RavenDB and Redis (NoSQL) where ever possible as these themselves are fast enough to allow UI testing to take place with persistence retrieval at a fast pace.
Granularity - Log everything. When your tests fail, let your logs tell you what went wrong. He argued what is the one thing you wish you had more of in a live system? Logging! So, put lots of it in there. Yes, a single test is touching lots of code so it is not very granular but let your logging report on how it progressed (and failed). Do not really on a large suite of very granular but highly coupled tests to provide you with detailed answers to where in your system you have a problem. Use logging. This makes a lot of sense as when you have a problem in the production environment, you will be looking at the logs, not the previous unit test runs...
He demonstrated this testing process in action - His UI tests were not remotely slow even though he was setting up and tearing down both the web server and data store between each test!
A number of tools were introduced which I had not heard of before to help with the testing process:
Phantomjs - A headless browser based on Chrome to execute your tests in.
Coypu - Helps with the browser automation process. Sounds very promising as it aims to solve many problems including timing issues.
Rob again had a focus on testing the output of a feature as the client would see it as opposed to the granular unit testing approach we have come accustom to - testing each class, public method, path of execution etc. Let the features drive your tests.
Combined with Ian's earlier session, this has given me a lot to think about.
