Testing in Angular World


This has been a hot topic for me lately. I covered testing AngularJS in couple of blogs but over the time I noticed people who are coming from .Net world who are not used to TDD model still fall back to the old style development that is without tests or tests have been added after the fact. I think, either of the approach is totally wrong. Testing is first class citizens in AngularJS and we should treat them that way. I want to go over couple of argument I got when I asked them about why there are no tests or not following TDD and lets discuss about it. I will try to answer the best of ability.

We are still learning AngularJS so I can’t write unit tests.

Ok it seems very valid point. I would strongly recommend understand and learn how to do tests first. Testing in Angular is simple and straight forward. I am going to focus on testing in the coming blogs. Angular support both unit testing and end to end testing (e2e) testing. It is easy to learn and get going fast. First understand AngularJS concepts like $scope, $http and others then learn how to mock them, the rest is nothing but writing simple tests. The bottom line, if you are trying to learn AngularJS, learn testing along with basic concepts and then go into the details of AngularJS features.

Now going back point made, if you want to do something and you do not know how to do it in AngularJS then you can not write test for it. Well that is not 100% true. If you are following TDD model, then once you get the requirement that you are trying write code for, you are suppose to write the test first. Now that you already know how to write test, go ahead and write the test first and then try to do the implementation. When you are trying to implement, you may run into problems, then modify the tests as you make progress to fit the model you are writing. This is true in end to end testing as well (e2e), you might have end to end test against a form and as you learn you realize that you need data table, change the e2e test for it. But write the test first. It will help. Again, with the tests, even when you are learning, it catch the unexpected errors that you might make when experimenting with new concepts.

We can’t write tests because there is no logic in the code.

Excellent point, AngularJS is used to develop client side code. So if you are developing application properly, client side should be as dumb as possible. So in theory, we will have MVC pattern applied to both client side and server side. So all the complex business logic will be in the server side controller. Since you do not have complicated logic at client side, client side code should be very simple. Normally when we start out the client side code will be very simple, we might make a webapi call to get some data, bind them to the variables and that is it. So for that we do not need any tests. Trust me when I say this, that is how all the projects start. Always they are very simple in the beginning and as project start to grow, you will have more complex logic in it and at that time, it will be difficult to add test to it.

In the above scenario, my suggestion is to add unit tests to all the functions you might add to client side code, even if it is single line assignment statement. You will also agree, it is easy to write test cases of single line assignment statement, so go ahead and add the tests for it. It might seem silly, but now when you run the test, you have code coverage for the functions you have written. The benefit comes in the next iteration you are asked to add some logic to that method with simple assignment. You already have tests so you know why that function exists to start with and with that understanding you can add more tests to support new functionality without breaking the old ones. In this case, you are trying to understand what that function suppose to do since you might not have written the code, so you do not know what it was suppose to do. With tests, it is easy to see the scenarios and understand what exactly those methods suppose to do. It gives the confidence in your change you are making.

AngularJS provides not only unit testing, it also gives e2e testing. So even if there are no logic in the client side, you are working with the data coming from server to display data. So you can write tests for it. Write your e2e test with mock data and verify if the UI elements display the data as it suppose to be. The cases where the developer thinks there is no logic in the client side, then you will have more e2e tests than unit tests.


Silverlight Starter Tips

I ran into two problems yesterday I thought I share it with you all and document it for future reference. I am using Silverlight 4 and VS2010.

1. I was writing a Silverlight Unit Test. When I compiled my simple test, it keep failing saying, Unable to load ‘System.Windows’ or its dependencies. It turned out, we need to make the System.Windows property to copy always.

2. I was debugging my Silverlight code and was able to step into my client code just fine. After some time, my debugging stopped working, none of my break points were hit. I was using Chrome as my default browser. I changed the browser to IE and debugging start working. So if you are a Silverlight developer do your self a favor and use IE other wise you will end up spending some time trying to figure this debugging problem.

Unit Testing in Silverlight – Continuing the path

In my previous blog I talked about few starter pointers for Silverlight Unit Testing. Hopefully you have converted all your Silverlight application fully testable by now. Now comes the next question, by default when you run the Silverlight test, it launches the web page and perform the test. It is all good and well as long as you are in your development environment, what if you want to run your tests as a part of your Continuous Integration (CI). There is a solution for that.

Fortunately I follow Jeremy Likness blog and some time back he wrote a blog about a open source project called Statlight. So today’s tip, if you want to run your Silverlight test as a part of CI, download and run Statlight. Please read Jeremy’s blog, he explains how to run Statight, so I am not going to duplicate that effort.

Unit testing in Silverlight – Starting points.

For all the starters who are venturing into Silverlight testing, I would like to pass on couple of pointers that might help in your testing endeavor.

1. Make sure you create test project using ‘Silverlight Unit testing project’ template to test your Silverlight application. Do not use ‘Test project’ template, it will add incorrect dlls and you will end up spend time trying to find out why in the world, there is version conflicts?

2. Most of all you might have Test Driven.Net installed in your Visual Studio, do not try to test a method by right clicking the method. Rather make the test project as start up project and run the project. When Silverlight test project runs, it gives an option run a specific test using Tags of the tests. Make sure you have a break point set in your test method and run only the test you want to run, it will take you back to your project for debugging.

3. You will run into a situation where you might want to read a data file sooner or later. This can be achieved in two ways.

One is embedding the items in request as resource at the client side.

The second approach is to put the required files in web site which is hosting your Silverlight test application and use ‘HttpWebRequest’ to load the files asynchronously. Loading data asynchronously is little tricky, but there are solution on the web. When you created the test project, if you choose to use dynamic hosting then the second approach is not going to work. If you decide to go with this approach make sure when you create the Silverlight Test Project to enable the check box to create web page to host the application. You can find the solution for loading files in Silverlight Forum. One thing to remember, in this approach your data files lives in web project.

I like the idea embedding the required files as long as they are not very huge. Also when you are using second option, your will end up writing your test methods in delegates. On the other hand, if you would use embedded resources, all you test will be in a single method.