Using protractor to e2e test ui-grid 3.0 (ng-grid)

In my previous post I described upgrading to ui-grid 3.0, which is the not-yet-beta version of ng-grid.  Over time this will offer significant benefits, at the moment it feels like a faster ng-grid.  As part of implementing it on my core application I needed to rewrite the library routines for my end-to-end testing using protractor.  These were reasonably tricky to work out, so I thought I’d post them here for anyone else trying something similar.

Upgrading to ng-grid 3.0 (ui-grid)

In this tutorial segment I upgrade the league application to use the new ui-grid (ng-grid 3.0).  Note that ui-grid is at this time still early beta, but offers the likelihood of better performance, a cleaner interface, easier edit in place, and removes the previous dependency on jQuery.

This code is built on the rails4 tutorial that I have previously written, and in particular uses as a starting point step 10 of that tutorial, which is available at github: PaulL : tutorial_10.

10: Adding devise integration – logon and security

In this portion of the tutorial we add Devise integration to provide logon to the application, and provide custom pages for password reset and account unlock.  This content is based somewhat on the equivalent content from the rails 3 version of the tutorial.

This will break down into three main elements:

1. Provision of a registration page that matches the Devise expectations and calls the Devise register method and password change method
2. Provision of a logon page that matches the Devise expectations and that calls the Devise logon method and associated methods such as password resets etc
3. Provision of functionality such that AngularJS can detect that a user is not logged on and redirect the user to the logon page, rather than just having each server interaction fail

If you’ve dropped into the middle of the tutorial, you can find the code for the previous section at github: PaulL : tutorial_9.  You can go to the index page for this tutorial, or you can hit the tutorial menu above and see all the posts in the Rails 4 tutorial.

Protractor and custom failure messages from Jasmine expect()

In this edition I use a custom matcher to provide tailored failure messages on my Jasmine expect() statements, allowing me to get context information other than “expected ‘true’ to equal ‘false'”.

I’ve been working to flesh out the functional tests for our application – I had allowed them to fall a little into disrepair whilst I did some architectural change, and it was time to refresh the suite.

As part of my architectural changes on the application itself I had refactored a lot of code to make it common.  Looking at the functional test suite it looked like it needed the same treatment.  In refactoring this code I wrote some helper routines, including one that checked (for each of view, editClean, editDirty modes) whether the correct fields and buttons were enabled.  All well and good, but the core of that logic was a loop through a hash, and Jasmine/Protractor reports only the line number – not which iteration through the hash we were on.  Making debugging annoying – how do we tell which field it is that is enabled but shouldn’t be?

Rails4, AngularJS, CSRF and Devise

I’ve been working further on my application, and run into a few challenges and issues with CSRF, so I’m elaborating a bit on my earlier post.  At some point my tutorials will be updated to deal with this, but for now this is a place holder that describes what CSRF protection does, where the issues lie, and what resolutions I’ve found to the overall problem.

Firstly, it seems that there are two general developer classes with Rails – those who are developing a Rails web application and therefore use Rails to create the pages, and those who are building an API using Rails, and seem to turn off CSRF protection and use an API key to authenticate (in a sense I see an API key as a long-lived username and password, so I’m not a big fan for applications that require strong security).

I’m living in a middle space – the application front-end is all AngularJS, and it’s calling Rails asynchronously using JSON.  But I’m still aiming to use Devise as my authentication engine, and I want to use CSRF to protect against malicious scripts that manipulate the API without the user knowing it.  The default configurations don’t really appear to deal with this situation well.

In discussing the solution, I’ll start with a simplified discussion of what CSRF protection should and shouldn’t do, and then what pieces are needed to integrate (reasonably) cleanly.

9: Adding the teams entity, and links from clubs to team

In this portion of the tutorial we’re going to extend to the teams entity, and build the links between clubs and teams.  This means passing parameters to our list controller, and dealing with optionality.  We’ll let people create a team from within the context of a club – in which case we auto-populate the club, and we’ll let them create a team standalone and pick the club from a drop-down.

This tutorial mainly consolidates what we’ve already done, but it lays the groundwork for some more interesting functionality later, including user authentication and an editable grid.

If you’ve dropped into the middle of the tutorial, you can find the code for the previous section at github: PaulL : tutorial_8.  You can go to the index page for this tutorial, or you can hit the tutorial menu above and see all the posts in the Rails 4 tutorial.

Editable ngGrid, with both dropdowns and selects

I’ve been working on making an editable ngGrid, allowing users to directly edit the grid rather than going to a detail page.  I’m seeing that there are two modes of operation – for simple things (maybe changing the status of a bunch of items), it’s easier to interact with the grid directly.  When you want to edit a full item, you’d do this in the detail page.

The aim is to have a grid that you can edit directly, and have it save to the server when you leave the cell you’re editing (this is a reason you wouldn’t want to edit the whole record this way – you’ll end up with lots of spurious saves if the user has lots of cells to edit).

An option if you’re starting a new project now would be to look at my tutorial on the beta ng-grid 3.0.  This isn’t ready for production use yet, but feels reasonably close, so if you’re 3 months away from production it could be an option.  It has a nicer api for editing.

Protractor and Dropdowns: validation

We use protractor for our end-to-end tests.  A variety of pages are suggesting that selection of dropdowns, and validation of dropdowns, is tricky.  And I think they’re right.

This post deals with a couple of code snippets that I’m using to deal with dropdown selection.

8: Deletes and resource error handling

Part 8 of the tutorial focuses on adding a delete button to our ngGrid, and adding error handling in case our rails application rejects our updates.  You can find the tutoral index, or hit the tutorials menu at the top and select the Rails 4 tutorial.

If you haven’t completed the earlier tutorials, you can get the code at github:PaulL tutorial_7.

7: Adding unit testing using karma

Part 7, in which we create karma unit tests for the list and edit controllers, including mocking the http calls.

If you’ve jumped into the middle of this tutorial, you’ll need the code from github:PaulL:tutorial_6, or you might want to visit the index page or hit the tutorials link above and look in the rails 4 tutorial.