Difficulty Approaching Test Driven Development in AngularJS using Jasmine and Karma

Question

I'm having difficulty getting started with test driven development in AngularJS using the Jasmine testing framework. I've had ample experience using PHPUnit and am very comfortable with it. Though I have not found the same ease doing test driven development in AngularJS using Jasmine.

I've read articles and tutorials, watched videos, looked through StackOverflow questions. I'm still having difficulty getting an appropriate word flow or getting into the thought process.

What is the thought process that one would go through when approaching test driven development in AngularJS?

Or in other words what is a though process that can be used when approaching test driven development in AngularJS?

Specifically what steps are there in the process? Do I start with the controller, the view, or the model?

What components of code do I go through as I follow through this process?

I'm looking for a thought process that is repeatable for building reliable unit tested applications in a variety of domains. Please list specific resources if you have them.

Answer 1

FWIW, you could walk through my sample code for one of my Pluralsight courses. This was the first AngularJS project I ever wrote, and I used Test-Driven Development with Jasmine and Karma.

To help me with my own thought process, I created many small commits, and whenever something interesting happened, I attempted to document it in my commit messages. You might want to review the commits to get an idea about how I went through it.

Since I based my code base on angular-seed, the first many commits in my repository are the commits from angular-seed. My first commit is this one.

There are probably many mistakes in my code base, as I was learning as I progressed, so I'm not claiming that this is exemplary AngularJS code, but I'm not too unhappy about it.

Answer 2

I'm absolutely willing to be corrected on this, as I'm not an expert, but my experience is that it is actually easier to start with the router, because I often know more about the routes the app is going to have to offer than anything else.

Each route needs a controller and a template. So whatever is is true, I'm going to have a controller for each of the routes. Thus, I can quickly work up tests for each controller. Not that the tests will test much at first (maybe just the existence of the controllers.) You can easily write a test for the router as well.

Then maybe take one controller at a time, writing tests for the behavior each is expected to implement, then implementing the behavior.

At some stage, it will probably be best to abstract some of that behavior out of controllers, refactoring it into services. Then the services can be tested.