Faster AngularJS tests using the component driver pattern

When writing tests I prefer to test multiple functions and their interactions at once, rather than constraining a test to a single function or unit. This ensures that the test operates in more realistic way, and avoids maintaining unnecessary tests over code paths that can’t be reached.

Protractor e2e tests for AngularJS interact directly with the DOM and usually provide more value than unit tests. I’m not interested in whether a controller behaves a certain way, I’m more interested in what happens when a user clicks a certain button on a page. But protractor tests are slow. In the largest AngularJS project I manage, there are over 300 protractor tests that take up to 15 minutes to complete, that’s a very slow feedback loop. In order to bring the test time down I’m turning back to AngularJS unit tests, using the component driver pattern to still inspect and interact with DOM elements.

Vanilla MVVM for Xamarin Forms

Want to do MVVM without the frameworks? Xamarin Forms provides everything we need to implement the pattern and make our ViewModels testable.

Note that some naming, patterns and code have been borrowed from the excellent FreshMVVM framework. This is a great lightweight framework to get started with if you don’t want to roll your own.

Simply put, MVVM helps us to abstract any UI logic out of the View and into a ViewModel to make it testable, while the data and business logic remains in the Model.

To avoid boilerplate code we’re going to create a couple of base classes, one for our Views, and one for our ViewModels.

Advanced Redux in Xamarin Part 2: Persistent Actions Middleware

In this second post in the series on advanced Redux in Xamarin, we'll look at how to persist Actions so application state can be restored when the app restarts. We'll do this by creating Middleware that will intercept each action and save it to a persistent store, then rehydrate the application state from that store on app startup.

No iOS code signing key matches provisioning profile

Recently my team have come up against this error a few times building a Xamarin app using Visual Studio 2017 both on the Mac and PC, and it took a bit to work out the fix.

No iOS code signing key matches specified provisioning profile ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’

Starting a promise chain to handle exceptions correctly

Here’s a little promises quirk that I’ve overlooked for a while. Generally we all write promises like this:

doSomething()
  .then(doSomethingElse)
  .then(doSomethingFurther)
  .catch(handleError);

And we know that any exception raised will skip to the catch handler. Except for the initial doSomething() call. If an exception is raised here it will be treated like a normal exception and stop executing all the rest of your code. So how do you deal with it?