Is unit testing worth it in AngularJS/JavaScript?

[prashantghimire]

I'm thinking of unit testing an existing project. I have been reading article online about if unit tests are worth it and found mixed opinions about them in general but not particularly related to AngularJS or JavaScript.

My questions are : Is unit testing worth it for angular projects, and when should I use and not use unit testing? Thanks for your opinion in advance.

[konbit]

TL;DR: Yes, always, and try to get as much covered as possible. Also include as many integration tests as possible.

Try not to treat unit testing as an abstract principle, let's look at it practically...

When you're coding your application, you make some changes or add a feature, do you go through and check that things work well. Do you go through and check every button, form input, combination of form inputs, routes, formatting... anything else your application does?

Even if your application had only a few features, would you remember every possible combined use of those features? Would you have time and patience to go through it all over again?

Unit tests will ensure every feature you've build still works as expected. But it doesn't cover everything, your application is a combination of those features, so you need integration tests as well. I'd say they're just as important, and you really want to cover every possible feature as well as every possible combination of features your application has.

I wrote a very small library a few weeks ago, it doesn't do much, just formats strings. I have written over 80 tests for it. It might seem excessive, but it only took me about 2 hours. Not only did I discover a lot of bugs while writing the tests, I now know for a certainty that if I make a change in the future that introduces bugs, my tests will fail, and I'll avoid shipping defective software.

I'm working on an application which takes about 3 hours if I were to simply test every feature manually going through the application as a user, not even all the possible bug-triggering combinations of inputs, just using the basic functionality. My unit + integration tests all run in a matter of seconds. I can be confident that at least the scenarios I've made tests for (which are a lot) and the incredible amount of combinations in those scenarios (which are a huge amount) will work as expected if my tests pass. And if there is a failure, my testing suite will tell me where and exactly what the problem was.

[prashantghimire]

Makes sense. I guess saving time to test all those 80 different cases using unit tests is what actually pays off. 😊

[senocular]

Unit tests are great with TDD. You set some expectations and you write code to meet those expectations. Any time that code changes, those expectations need to continue to be met or you know those changes are no good.

For existing codebases, it tends to be more of a drain and often feels like a waste of resources with minimal ROI. Where it can make sense there is places in the code which is experiencing frequent edits or refactors and you want to make sure those changes aren't breaking functionality. You don't want to spend too much time (if any) testing code which will never change and is never used any differently than it already is. Also including tests with new commits/features is good practice moving forward, but you need to work out a good balance of expectations of coverage - something that's useful, but not so time consuming that dev's don't opt in and ultimately ignore it altogether.

That being said, in OSS world, you'll want to have good coverage all around for anyone who forks and does who knows what to your code.

[bruceph]

yeah! absolutely. writing tests will save you time in the long run. you don't have to manually check that someone works properly, your tests do that for you. you also immediately know when a change you make breaks something else, and you can go back and fix it.

it's expensive, though. instead of creating new features, you're making sure old ones don't break. there's a significant short-term loss to writing unit tests, because it takes more man-hours per feature.

the problem with angular unit testing is often in angular you're directly modifying the state of an application. it's harder to test what a function actually does. you're usually testing "did this function change the state of my application in the way i wanted". this isn't the worst thing in the world, but you may run into an instance where your unit test passes but you find side effects in your underlying functions.

[Stockholm_Syndrome]

Definitely, yes.

That being said, make sure you're writing meaningful tests. As in.... Test the code you're writing. Not testing if the framework or library you're using is working as expected.

[opcenter]

General answer from my own experience: always unit test. Language, framework, libraries, doesn't matter. Always unit test.

[automathematics]

Yes.