Unit Testing Front End Logic

Question

We have tried to introduce unit testing front end logic on a recent project and the value of the tests are being questioned.

We were not code reviewing the tests so the quality of them is poor, developers copied poor tests creating more poor tests and so we have a lot of crap tests.

I still believe there is value in testing the presenters (we use MVP) but getting people on board with this is more difficult than I originally thought.

How can I get people into thinking front end tests are valuable and has anyone got any good resources to point me to, to back me up with this?

Thanks...

Answer 1

Unit testing front end logic is extremely hard since there are many parts that make it up like server side code changes to the front end and client side changes can all affect how the application appears.

On the Google testing blog they talked about the value of testing all the parts of a MVP and the value of testing AJAX by stubbing the expensive parts here. Misko Hevery talks about the different tests here and I feel that the Front End tests fall into his large test category so always have the chance of false negatives/positives but they need to be sorted because they still offer a lot of value

Front end tests are extremely valuable as they check the user functionality hasn't dropped off. This is why tools like Selenium and Watir are so popular.

---

Answer 2

The question for me would be the trade-off between the costs of maintaining the tests and the probability of catching bugs that would not be caught otherwise. Presumably you will still have some visual testing of the actual UI (you'll do really well to test the aesthetics otherwise).

Can you for example focus only on some aspects of the Presenter. For example a non-trivial formatter, exercise that with lots of interesting values.

I suspect that one way to persuade is to proceed slowly. Try to find low-effort tests initially.

Answer 3

Fix the broken window. here is a link to the theory http://en.wikipedia.org/wiki/Fixing_Broken_Windows

A successful strategy for preventing poor code quality is to always keep your code base clean and in prestige condition. This means clean up all the bad code. It might be painful, and time consuming, but you will need to do it anyway.

After we removed all the compile warnings on our project, we found that our code quality has been improving. People start to care what they check in, since we send out a signal that it is not ok to checkin bad code(even warning is not ok), and no one wants to be the first one to break the window.

Answer 4

Another pitfall when testing UI is that it is especially easy to end up writing tests that test the framework and not your application. Or said in reverse: it can be challenging to write test that actually test your UI and not the UI framework.

For instance, some teams end up writing lots of useless tests like:

Given a button, when the button is clicked, the event handler should fire.