Writing Angular Unit Tests After the App is Written?

Question

I've inherited a medium sized angular app. It looks pretty well organized and well written but there's no documentation or unit tests implemented.

I'm going to make an effort to write unit tests posthumously and eventually work in e2e tests and documentation via ngdoc.

I'm wondering what the best approach to writing unit tests is after the fact. Would you start with services and factories, then directives etc or some other strategy? I plan on using Jasmine as my testing framework.

I should also mention that I've only been with the code for a few days so I'm not 100% sure how everything ties together yet.

Answer 1

At the end of the day what you need to know is that your software works correctly, consistently, and within business constraints. That's all that matters, and TDD is just a tool to help get you there. So, that's the frame of mind from which I'm approaching this answer.

---

If there are any known bugs, I'd start there. Cover the current, or intended, functionality with tests and work to fix the bugs as you go.

After that, or if there aren't any currently known bugs, then I'd worry about adding tests as you begin to maintain the code and make changes. Add tests to cover the current, correct functionality to make sure you don't break it in unexpected ways.

In general, writing tests to cover things that appear to be working, just so that you can have test coverage, won't be a good use of time. While it might feel good, the point of tests is to tell you when something is wrong. So, if you already have working code and you never change it, then writing tests to cover it won't make the code any less buggy. Going over the code by hand might uncover as yet undiscovered bugs, but that has nothing to do with TDD.

That doesn't mean that writing tests after the fact should never be done, but exhaustive tests after the fact seems a bit overkill.

And if none of that advice applies to your particular situation, but you want to add tests anyway, then start with the most critical/dangerous parts of the code - the pieces that, if something goes wrong you're going to be especially screwed, and make sure those sections are rock-solid.

Answer 2

I was recently in a similar situation with an AngularJS app. Apparently, one of the main rules of AngularJS development is TDD Always. We didn't learn about this until later though, after development had been ongoing for more than six months.

I did try adding some tests later on, and it was difficult. The most difficult aspect is that your code is less likely to be written in a way that's easily testable. This means a lot of refactoring (or rewriting) is in order.

Obviously, you won't have a lot of time to spend reverse engineering everything to add in tests, so I'd suggest following these guidelines:

1. Identify the most problematic areas of the application. This is the stuff that always seems to break whenever someone makes a change.

2. Order this list by importance, so that the most important components are at the top of your list and the lesser items are at the bottom.

3. Next, order by items that are less complex.

4. Start adding tests in slowly, from the top of your list.

You want to start with the most important yet least complex so you can get some easy wins. Things with a lot of dependencies may also need to be refactored in the process, so things that are already dependent on less should be easier to refactor and test.

In the end, it seems best to start with unit testing from the beginning, but when that's not possible, I've found this approach to be helpful.