What type of Angular tests will give you the highest ROI?
The 3 minute guide to deciding what part of your Angular project you should be testing.
Say, anyone making their first attempt at writing tests for an Angular app might rather grab a drumstick and herd a mob of hairy cats down the street instead.
It’s easy to get lost trying to decide which pieces of the Angular application to test.
Er… what parts must I test and what can I skip?
Do we need 100% code coverage?
And should I be writing tests for that front-end UI stuff that’s always evolving? UI tests tend to be brittle so where should an Angular developer set their mouse traps?
Most importantly, how do I make sure that I get the best ROI for my time?
That my friend, is a great question. If you want a quick answer then go ahead and skip to the bottom of this article in the summary section. Otherwise, we’ll peal the covers back a bit and look at the main pieces of an Angular application and the priorities they deserve.
Components are… well… components.
They are the most basic UI building block in an Angular app and their only function should be to display data.
A component should have no concern as to business logic or where the data came from. It should only focus on taking the data it’s meant to receive and presenting it to the user in a meaningful way.
In general, it’s a waste of time to test these heavily. Especially as they’re prone to lots of change as an Angular app grows and evolves.
To focus lots of developer energy on making sure your components are completely tested is usually a poor investment choice.
Here’s where you’ll take an aim and make a great shot!
Assuming that your Angular app has followed general best practices…
…and uses services to handle business logic, data access, HTTP calls, and all the other spicy background stuff…
…then this is where anyone writing tests ought-a be licking their lips.
Make sure your Angular services are tested well. By focusing on this you’ll have a greater guarantee of better ROI.
Not sure how to get started? The Angular website has a great guide to get you started.
Definitely put those custom pipes to the fire. Once again, these play an important role in business logic. Making sure they’re working properly is a great way to get a better ROI when writing tests.
So what should you test?
Write bug traps for every piece of the application that contains business logic. This would be pieces like…
- Custom pipes
- Helper functions
- Stage Management
By focusing on the pieces with the business logic and making sure it’s tested well you’ll be cutting to the heart of the matter and honing in on what really matters.
And one final tip…
You should aim for 60 to 80 percent code coverage when writing tests for your Angular application. And rivet your eye on making sure the business logic in the application is well tested.
And that’s it! Please pound that 👏 button. Thank-you!
(Angular) Globally enforce a coding style using TSLint + Prettier + Husky
Here’s how to automate and enforce a global coding styling so that you and your developers can focus on what matters.
How to build a highly effective Angular team
What is the secret sauce in exceptionally effective Angular teams?
How to add a spinner to an Angular Material button.
Err…wouldn’t it be nice if Angular Material had a button with a loading spinner?
Originally published at https://danielk.tech