In an earlier posting I discussed, briefly, why Angular is suddenly so popular, and demonstrated how to get started with Angular without writing a line of JavaScript. It’s time now to turn our attention to a slightly more realistic example.
Many lessons on Angular pay lip-service to the importance of unit-testing and test-driven development, but virtually none actually practice it. This series will buck that trend and teach Angular and testing Angular at the same time. In the long run, this will be faster and better than trying to tack testing on at the end.
Test Driven and Behavior Driven Development.
There are many discussions of why testing is critical to writing solid, maintainable and reliable software, so I won’t go into all the arguments here. I will, however, briefly define the three terms in the headline.
Test-driven software development takes the practice of writing unit tests, which test small, self-contained “units” of software (such as methods) and inverts the process, stating that the tests should come before the implementation is written. There are many good reasons for this, including the fact that the test acts as a specification for the implementation, and when the test passes, you know that the implementation does what it should.
Behavior Driven Development (BDD) was developed by Dan North in response to issues he encountered with Test Driven Development. These included questions about how to get started, how to decide what to test, how much the tests should cover and so forth. The distinction between BDD and TDD is somewhat arbitrary, but a number of tools and conventions have arisen around BDD that focus on the business and technical requirements of the code you are writing.
One of the key tools for BDD is the testing framework, and one of the most popular for JavaScript testing is Jasmine. A principal goal of Jasmine is that it is easy to read, as you’ll see as we go forward.
Clean Code Principles
There are many principles to good Test-Driven/Behavior Driven programs, most of which are captured in Robert Martin’s seminal book, Clean Code: A Handbook of Agile Software Craftsmanship
We will focus, initially on the Red – Green – Refactor cycle. The basic approach is to create a test before creating the code to make the test pass. This is the Red phase, when the test will and must fail. The key to writing this test is to test exactly one (small) thing and nothing else. When it fails, you want to know exactly what failed.
Next comes the green phase when you write the code to make the test pass. Again, you write just enough to make it pass, and no more. When it does pass, the test acts as a spec for what was tested.
Finally, we refactor: clean up the code we wrote and ensure that we haven’t broken anything by running the tests again, they should stay green.
We’ll talk about many of Robert Martin’s other design principles as we go, but let’s get set up to write Angular with tests.
Software You’ll Need
By now, presumably, you’ve installed the latest Angular libraries, and/or you are using the CDN. For testing, you’ll need the Jasmine libraries. We’ll be working with Jasmine 2.x, the latest Jasmine. The easiest way to download what you need is from the GitHub site.
You can install Jasmine with Node.js and npm, but you can also just copy the javascript files you need into your project.
For this series I’ll be using WebStorm 8. It has excellent support for writing Javascript programs and for third party libraries such as Angular and Jasmine. The truth is, however, you can work with any text editor, and you may prefer a free editor. Alternatively, if you are set up with Visual Studio, you can obtain Angular through NuGet and then add Jasmine.
Key to getting start is your SpecRunner.html file, which acts to run the tests you’ll develop.
Getting Started – File Organization
There are many good ways to organize your files for an Angular application. I’ll demonstrate one way, but it is not the only way.
In the figure to the left, I’ve laid out a simple application for tracking expenses. This is the application I’ll be building in my forthcoming Pluralsight course AngularJS Testing From Scratch. We’ll repurpose it here.
The red box I’ve added towards the top of the figure encircles the Jasmine files, which you can see are listed under the lib directory. Associated with these files is the SpecRunner.html file in the red box at the bottom. The blue box shows the Angular files. The green box shows the files we picked up from Bootstrap (not required, but does help with making a nice looking site). The brown box shows where our source files will go and the magenta arrow points to the spec directory.
The spec directory holds our tests (called specs in BDD because they represent the specifications for the application).
Starting Simple – Red Phase
Let’s start simple, with a JavaScript example, rather than diving into both testing and Angular at the same time.
Our high level requirement says that we’re building an Expense Tracker, and as such we need to be able to create an expense item.
We start by creating a spec. In the spec folder add a file named expenseSpec.js For our first spec, we’ll posit the creation of an expenseItem that holds an amount (the cost of the expense).
We begin with a describe statement,
This statement tells us what we’re testing and will hold one or more individual tests. Each test begins with it and describes a very specific requirement. For example, we might state that there will be an expenseItem with a specific value, We start by saying that it will have the value 100,
We next posit the existence of an expenseItem that has an amount property, and in the body of the it we use the expect statement to indicate what we expect the result to be. Expect is paired with a matcher. There are many built-in matchers, and it is easy to write your own as well. Two of the most popular matchers are .toBe and .toEqual. Here is our code,
We are in the red phase, and we expect (and want) this test to fail. To run this, however, we need to edit our SpecRunner.html file,
Notice above that we have included expenseSpec.js. That is how the SpecRunner knows to run our spec. If we right-click on SpecRunner.html we can select Open In Browser and pick the browser we want to run our tests.
As you can see from the image to the left, the test fails. This is what we expect, we’ve not yet implemented the functionality. But this is good. Now we know the test can fail. There’s nothing worse than having a test pass repeatedly only to learn that a poorly constructed test can’t fail under any conditions!
Starting Simple – Green Phase
The failed test tells us what is wrong: expenseItem is not defined. Let’s define it by creating a file in src/app/Expense named expenseItem.js:
This is enough to make the test pass, and that is all we should do at this point. It is important not to get ahead of our tests.
Typically we’d move in very small steps for a first test, but for this posting, let’s zip ahead a bit. We’ll reorganize our test to handle two objects, an expense, and an expenseItem. Here is our description of them,
This works, but it has the (dreaded) duplicate code (the first two lines of each it statement). We can fix this by creating a beforeEach function. As you can tell from the name, this function will run before each it statement,
Much better. Now we run this and we have two tests fail. Excellent.
We can then implement the expense to take an expenseItem.
Remember to add expense.js to your SpecRunner.html and run your tests again. Success!
Test Characteristics
There are many important characteristics of good tests, but we’ve already seen a few
- Tests are fast
- Tests are unambiguous
- Tests only test one thing
Tests must be fast or you won’t run them, and running them repeatedly is the heart and soul of BDD. You wan to run all of your tests after each change, and you won’t do that if they take a long time to run.
Tests are unambiguous in that they either fail or they pass. There is no ambiguity. A failed test fails completely.
Test only one thing so that if your test does fail, you know just what is wrong. By testing frequently and in small steps and with tests that are highly focused, you almost never need the debugger; your test tells you just what went wrong.
Next Steps
We have a couple good, if simple tests, but they are not testing Angular. In the next posting we’ll turn our attention to changing this to be an Angular app and we’ll continue testing as we go.
You may also be interested in this podcast with the author of the NG-Book that touches on many of these topics.
The post Angular Part 2– Behavior Driven Development appeared first on Falafel Software Blog.