Testing the frontend?

Despite working on the Frontend, most of my work is sort of the 'business side' of the application. I've been using mostly Angular for the last 2 years - and it makes it pretty easy to get going with tests.

The view layer is pretty well decoupled from the business logic layer - and we have gone through a few major revisions of the UI, with little need to touch the BL side of things.

We have also done some pretty major refactors on the BL side - without needing to touch the UI much, and have had little regressions crop up because our tests were catching things.

An example of which how unit testing was invaluable to me recently - the backend I'm working with is a blackbox - I have no control over it. One week, they had done 2 or 3 different breaking API changes on us. Since all of the code around it was pretty well tested, with the data mocked out - the general process of fixing the code was : Change mock data to reflect new API data, run tests - see what failed. Fix code, get tests passing - then do a sanity check on the application.

It's something where if there hadn't of been unit tests - what was an hour or two bug hunt in the morning pre breaking change, would have taken much longer, and far less confidence in the fixes.

Or, there are times where I am falling into 'F5 development hell' - do a tweak, reload the browser, do a few manual steps - click on a button and then look at the results.

If I can force myself to step back and think 'how will I test this?' - close the browser window, get into my test suite - and start making a testable solution where it's then a matter of 'hit save, watch my tests run - adjust, watch tests run'. This is especially useful when there is X input, that goes through a bunch of calculations and then I expect Y at the end. How it's represented on the UI is more of a side-effect than the primary purpose.

Another important thing with unit tests - it can help give you confidence in refactoring. How many times have you been a little rushed to do something, committed code that was an ugly mess - thinking 'I will clean it up later'.

Then later never comes, or if it does come - you end up breaking things in ways that you didn't expect. Unit tests can help give you a bit of confidence with refactoring, especially if it's done at the right level (ie: testing the 'public' aspects of your class/module - and not the individual internal implementation details)

The main thing to consider when unit testing code - it's not just about writing tests for code, it's about writing testable code.

Unit tests are not a magic bullet, and it's taken me time to start doing them decently - but it is getting to the point now of which I am finding that they are saving me time, instead of costing me time. When I can get like, 80% of a feature developed before even needing to load up my browser - it's pretty damn nice.

I'm still not that great with E2E testing - and it's probably the next piece in the puzzle that I'll start trying to tackling next.

/r/Frontend Thread