re: Does your team write code tests for front-end code? VIEW POST

FULL DISCUSSION
 

Absolutely.

Because...

Anything that can go wrong will go wrong. - Murphey's law

  • Front-end code changes more frequently than any other piece of code. You are probably going to introduce more bugs on the UI than anywhere else.
  • It's madness to test the UI on every single browser / OS / device by hand.
  • Testing the app by hand is primitive and mind-numbingly boring. You can actually make mistakes testing because you are brain-dead / half-asleep.

Everyone in my team writes UI tests, partly because we built UI-licious, a tool to automate UI testing for web apps.

The problem with front-end testing...

Is that with the way the testing tools work today, tests are wired to the actual design and implementation of the UI, and quickly become obsolete.

This means that you need to create multiple tests to test desktop and mobile designs for the same test scenario. And whenever the design or code is changed, the tests needs to be updated. It's a colossal waste of time to be going back and forth to fix broken tests.

Plus the use of CSS selectors, XPATHs and magic waits make the test horribly unreadable and difficult to maintain.

Tests should be independent from implementation because it is supposed to test if the implementation follows the specs. It makes no sense at all for tests to be wired to implementation. And why does it even matter what front-end framework - Angular/React/VueJS you use?

What then, does specs mean for the front-end then? The user's journey. That's how your app deliver's value to the consumers.

That's why I ended up creating UI-licious, because:

  • it should be possible to write a test once and run it against any desktop/mobile/present/future UI design, built with any front-end framework,
  • it should be possible to TDD front-end development, and
  • it should be possible to test of your app works for any user - people with and without accessible needs.

The UI-licious test engine does the heavy lifting of deciding how to correctly interact with any UI given simple commands, even in ambiguous scenarios where multiple elements are similar. Under the hood, there's some dynamic code analysis and good old-school AI involved to do this.

In any case, front-end code is still code, it changes, it has smells, it has bugs. Is there a good reason not to test it besides the lack of good tools to do so?

code of conduct - report abuse