As someone who spends quite some time writing and checking unit and e2e tests I’ve started noticing a trend I’m somewhat confused by. There have been multiple occasions in which I’ve encountered test logic (repeatable and single use) in either test specifications or page objects. So I decided to share my approach to writing and foremost separating my test code into three categories. Those being: Specifications , Sequences and Page Objects. I’ll describe my views on these categories below.
In a modern service landscape, especially when using containers, you are probably using something like the ELK stack (Elasticsearch, Logstash, Kibana) to flow all the logging into. But how to find from all those loglines what caused the nasty bug after a innocent buttonpress? One of the easy answers to this is what’s called a correlation id - basically a unique number assigned to that buttonpress which gets carried around between the services and added to every logline. Sounds good you say? it is so let’s see how to do this. First we need to generate and send the correlation id from the browser. To do this in a transparent way we add a header with every request to the backend and put a unique id (UUID is mostly used) in it. Below is a piece of AngularJS code to do this:
In AngularJS, especially when you’re using a 'modern' Web Component like approach, you often have directives request the same information from your services multiple times. Since we’d rather not do round-trips we don’t need to to save on server resources caching is our go-to solution. In this post I will show two different approaches to caching resources: the built-in angular way using $resource and a home-grown solution.
For several of my projects I required a list where input items could be dynamically added and removed. Because i saw uses for this over and over i created a component which i'm sharing with you here. The component ended up like the code below. Where i used a template generation function in order to create the ul and li elements. I'm using the angular.element function to create nodes as a method of preference.
From May 18-20 myself and Richard attended the Google IO 2016 conference. We both visited different tracks and have some different experiences we'd like to share. Here are mine. Read on about topics in the likes of VR, Progressive Web Apps, and Artificial Intelligence. For a quick impression have a look at the photo album.
In AngularJS 1.5 we can use attribute binding to allow easy use of input-only, output-only and two-way attributes for a directive or component. Instead of manually parsing, watching and modifying attribute values through code, we can simply specify an attribute binding by adding a property to the object hash of:
Although I'm a great fan of using the ($q) Promise API in AngularJS, I never really liked using
$q.defer() and its Deferred API. I always found using
var deferred = $q.defer() together with
$.reject(..) to be too verbose. After recently checking the $q service documentation I stumbled upon the $q constructor that results in way less verbose code. To illustrate the usage of the $q constructor I will create a function that wraps the result of a Geolocation#getCurrentPosition invocation as an AngularJS
$q promise. Using the traditional
$q.defer() approach the function wrapper will look like this.
Since I had issues finding a good explanation on how to tie together a controller and a directive with isolated scope I decided to create my own blog post on this subject. This repo contains a runnable example of the solution. It contains a Spring Boot Web Application that can be started to act as a HTTP server but all the interesting stuff is in the src/main/webapp folder.
NOTE: ngImprovedTesting is AngularJS library to make mock testing AngularJS code more easy.
For more information about ngImprovedTesting be sure to read its (updated) introductory blog post.
This third and final part in my Stateless Spring Security series is about mixing previous post about JWT token based authentication with spring-social-security. This post directly builds upon it and focusses mostly on the changed parts. The idea is to substitude the username/password based login with "Login with Facebook" functionality based on OAuth 2, but still use the same token based authentication after that.