Testing In Angular

Author: Ben B. Ben B | 9/9/16

When talking with potential clients, I’m often asked about my experience building tests. Test driven development is a buzzword right now and there is a lot of differing opinions. Some developers want to test 100% of their code and others as little as 20%. The common thread is that everyone agrees that testing is important. The trick is doing it right.

Most of the following tips are going to be related to testing Angular applications with Karma and Protractor

How To Do It Wrong

Unfortunately, doing it right isn’t as common as you might think.

I don’t think some developers realize how costly it is to build tests. I’ve seen tasks where writing the test takes 3X longer than writing the actual code. That is definitely an investment and every investment should have a payback. But do they? Sometimes.

If you’re writing a function to calculate total dollar amounts for an eCommerce site, then the investment is well spent. If, on the other hand, you’re writing a test to make sure a button appears on a page, don’t waste your time (unless it is the panic button at a nuclear facility :).

I think the best way to know if you’re doing it wrong is if you find yourself just duplicating code from test to view/controller/service/etc.


  • Write simple tests just to see if functions or objects exist that were explicitly written. Of course they do!
  • Write tests to see if simple page elements exist. You just wrote them didn’t you?

This isn’t an exhaustive list, but I hope to add onto it over time. I’d love to hear your thoughts!

How To Do It Right

I recently went through a bunch of test written by other developers. This was a very helpful exercise and helped me formulate the following things that I think should have tests.

The main question I use to determine what to test is whether someone else could change something outside a file and break my code. If the answer is yes, there should be a test.


  • Check that the route loaded (Protractor)
    • If there is a problem with a URL, you want to know about it.
  • Make sure that templates are loaded correctly (Protractor)
    • You can check for the main class of the page just to make sure the template doesn’t have an issue. Notice I didn’t say “main ID.” IDs are less versatile then classes, so I don’t use them anymore. If I’m concerned about attaching JS to a class, I’ll but a “.js” in front of it (e.g. .jsSomeClass). When testing, I’ll but a “.test” in front of it.
  • Check to make sure that directives load (Protractor)
    • If someone removes or changes a directive that you used, you definitely want them to know about the dependency.
  • Check to see that any DOM changes were successful. (Protractor)
    • For instance, if you click a button and something should appear, check that it did.
  • Check to see that route changes happen correctly (Protractor)
    • You definitely don’t want broken links in the future.
  • Check if a controller is defined (Karma)

I have a lot more to learn about testing, but these are some of my thoughts recently. Please comment if I missed something or didn’t think through something correctly. I’m always trying to improve.


About The Author

Ben currently works as a senior developer and technical business consultant outside of Boulder, Colorado.

More about this author

About Buink

Buink Web Development is a development shop founded in 2009 by Ben Buie. For years, Ben built and modified web assets for clients in Utah. In 2011, he moved the company to Colorado and in 2015 he started taking on new clients full-time.

Buink’s Core Values:

  • Cost effective technology (with business strategy in mind)
  • Eloquent, maintainable code
  • Responsive and transparent communication

Read more about Buink

Connect with Buink

Connect with Buink via email, send us a message, or subscribe to our blog.