Twitter Call us on +44 (0)1256 486557

Should you test views in an MVC application built in Sencha Touch?

A common debate is whether or not to write unit tests for views in Sencha Touch.  In theory an MVC app should be made up of:

  • Fat Models
  • Skinny Controllers
  • Dumb Views

So what does that mean?  Well, the majority of your business logic should be inside your models and stores – that’s to say anything that deals with the formatting, retrieval and storage of data.

Controllers should simply pass data between the views and models and control interaction with the views, listening to events and so on.

Finally views, particularly in Sencha Touch where the bulk of the UI is actually built for you and is not code you write, should 99% of the time be relatively straight forward in what code you are actually writing.  So you would expect to have some config such as which component to use and possibly some kind of loop that traverses data passed to it for rendering.

However, you wouldn’t expect any business logic to reside inside the views and therefore it could be considered that the overhead of unit testing your views would not be repaid in the potential benefits as they are relatively simple.

Much better, some would argue, would be to have unit tests for the Model and Controller layers and then using automated tools such as Selenium or Siesta to perform behavioural testing where the UI is actually used in a web browser and is therefore tested.

To summarise there are pros and cons to this approach.


  • Lower overhead of unit testing.
  • No mocking and stubbing of UI elements.
  • No interaction with the DOM in unit tests (always a bone of contention with tests as you need to clear down the UI after every test, so the setup for each one can become cumbersome.
  • Can be covered in behavioural tests that you’d likely be performing anyway.


  • You have to wait for behavioural tests to run before knowing you have an issue with the views which would normally be considerably longer than unit tests.
  • Any logic, however simple, is not unit tested and therefore cannot be guaranteed to be defensive against edge cases – this is much less likely when unit tested.
  • Means views are less likely to be written test driven as behavioural tests are far more likely to be written (in any detail at least) after the code is done.

We don’t currently unit test views as we are relatively strict with what we allow in them and consider that you will often end up writing integration tests by accident.  It’s also possible that you end up testing the Sencha framework rather than the view code you’ve written.

That said, we are constantly reviewing our processes and it’s not to say there’d never be a case that we’d test views, but as a rule we don’t at the moment.