There are many tutorials available that provide insights into the use of specific testing frameworks or guidelines on how to write end-to-end tests, but very few of these cover what the end point of these tests should be. Should the end be stubbed API calls or a fake API? Or should it be a real API, but with a special test database?

Every one of the various testing approaches that are available have their own drawbacks and choosing one for your project always involves some type of trade-off. Some tests are too brittle and fail randomly, while others are too time consuming to setup and maintain. I recently discovered an approach that is somewhat of a compromise but seems to require little effort to setup and has proven itself capable of finding real application bugs.

This article describes the end-to-end testing of single page applications (SPA) that are built on an AngularJS or other JS framework. The testing of SPA differs from testing traditional web applications because SPA consists of client-side app and back-end API. This gives more seams for mocking and more testing approaches to choose from. Let’s review which options are currently available for testing SPAs.

Whenever I design the REST API, I take a look at how other people have designed their APIs. There are a couple of benefits to this approach. Firstly, I get some ideas of the typical problems I may encounter, which saves me from reinventing the wheel. However, perhaps what’s even more important is that I gain an insight into whether a common approach is typically used to design a given API feature.

I recently worked on my first AngularJS project. It was a bit of surprise to find out how much work you need to put into building a set of generic components for your project.

AngularJS claims to be a toolset for building frameworks rather than a framework on its own. Even though it provides plenty of core functionality out of the box (e.g. routing, data-binding, etc.), you will still need to build many components for common tasks such as loading panes, notifications, etc.

The project that I worked on was an intranet type application, used mainly to view and edit various types of data. As such, most of the components that I describe below deal with improvements to form usability.

To give you an idea which features are not in AngularJS, I describe some of the custom components that we built for the project. For some of the components, I provide implementation ideas while for others I only provide design ideas but both should help you get started on your first CRUD AngularJS application.

Recently I had to build a few web pages with sortable tables. Where you can click on a column title and it will order records. Knockout was already used on the project to render pages.

I went to google to see if there is already a solution to order tables generated by knockout. All I could find is bridges to massive JS libraries, which control rendering of entire table, dictating me how to structure my data. Such solution didn’t work for me, because I wanted to have a full control over table rows rendering, as my tables had custom controls and widgets bound to my view model.

Building and maintaining large scale applications in JavaScript is complicated. It is especially becomes problematic when many developers work on a single project. One of the ways to approach this problem is to use some other language, which compiles down to JavaScript. There are various such projects out there: Coffee Script, Google Dart, Google Web Toolkit, TypeScript, Script#.

Recently I have been involved in maintenance of the project built using Script#. It lets you write code in C# language and compile it to JS. I have never heard about this tool before faced it on the project.

I have been playing with TypeScript recently using Visual Studio. It is easy to get started with TypeScript in Visual Studio. All you need to get it working is install TypeScript Visual Studio plugin from TypeScript website and Web Essentials extension. Works like a charm.