More specifically, with regards to ATDD (sort of BDD flavored, or some could argue what was actually intended in the first place by TDD) should be there much UI testing?

As I have been testing my UI components on my flavor of the month client-side MCV framework I find that I haven't really been testing much in the components themselves, only the modules they use.

For example, on a book website with Authors and Books if I am testing the Book listing page for an Author, instead of testing that the elements are rendered in the component properly (e.g. the li elements for each book, the parent ul, etc.) I would move the logic into a module for fetching those Books for a specific Author.

To take the example further, if there was some logic for interacting with one of the Book elements rendered in the ul then instead of checking that a handler was triggered I would just make sure that the handler is being tested properly.

It feels like if I test the UI rendering of the Author and his/her Books on the client side it's too tied to the implementation, and similarly with the event handler it marries me to the event handler so I can't refactor.

Is this the way to think about client-side testing the UI? Perhaps I just need some acceptance tests (e.g. Selenium) in this case to fill in the gaps?

  • 1
    Your strategy should be to push as much logic as you possibly can away from the UI into things like View Models and Presenters, so that it becomes unit testable without relying on automated UI tools like Selenium. Commented Jun 2, 2018 at 23:26
  • @RobertHarvey what about click handlers, even handlers and the like? Does this mean that component testing for client-side components as part of an MVC model should be very limited? Commented Jun 2, 2018 at 23:28
  • 2
    Event handlers are the way you hook up your UI to your already-tested ViewModel/Presenter code. Commented Jun 3, 2018 at 16:48
  • @RobertHarvey should we test the fact that the correct already-tested code gets called in response to what we want to have trigger it? Or is that not worth testing? Perhaps it should be tested via an end-to-end test a la Selenium or something similar if it is really important, otherwise not worry about it? Commented Jun 3, 2018 at 19:15

1 Answer 1


Good question. If you are following TDD the you aren't supposed to write code which doesn't have a test. But I have never seen this applied to UI.

There are UI test tools such as selenium which work with websites. So creating a test to count the list items in the html is easy enough.

Checking that they 'render correctly' is a bit harder. You can take screenshots and compare, but obviously even expected changes with dynamic data will fail. Also your testing the whole page with this approach.

If you are taking your product seriously then UI tests are must.

To get them working reliably and fast enough to be a successful TDD approach sounds like a challenge. You might have to put some time in to develop tools and systems around this before it becomes viable

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.