Introducing Practical AngularJS

Mon, 25 Nov 2013 16:16:09 +0000

I was recently at Devoxx in Antwerp, primarily because I wanted to get involved in some of the sessions that were being hosted by guys from the AngularJS team at Google. I’ve had a chance to work a little with Backbone and KnockoutJS and had been recently deliberately holding off looking at AngularJS so I could hit the conference and workshops fresh and unencumbered with any preconceptions.

The sessions were great, and since then I’ve been working on a couple of projects that use Angular. As I’ve always found writing about a topic a great way to really cement what you know about it, and to understand where the holes in your knowledge are, I’ve started a new series of articles called ‘Practical AngularJS’.

This series is a little different to others I’m working on at the moment (such as the seemingly endless SharpShell articles and Learn JavaScript which is taking some time) as I’m writing it on my own blog rather than on the CodeProject. The reason behind this is purely push me into getting better at handling my blog (particularly the code samples) and because the code I’m writing doesn’t need to be associated with download links and so on, it can all be in fiddles.

Anyway, enough chatter - part one of Practical AngularJS is now finished. It’s a new series, so it’s early enough to have a say in where it goes, please comment and share and let me kn0w whether you find it useful, pointless, or anything in-between.

As a short teaser, in Practical AngularJS Part 1 - Introducing AngularJS we take a look at what AngularJS is, why we’d consider using it and when. We start out with a trivial task for a web application, and see how it quickly becomes a bit sluggish and painful to do certain things, then see how using AnguarJS can ease that pain, letting us focus on the important stuff and it help out with the grunt work. We take our initially messy app and make it a lot more manageable, and look into how we can with our new structure start to write unit tests for the logic.

So this is the bulk of Part 1. Unless there’s a strong push for another topic, Part 2 will focus on testing. Testing is core to the development ideals of the AngularJS project and is something that it was built in mind for. We’ll look into how quickly we can write unit tests, and the flexibility that we’ve got.

Rather than advocating patterns such as BDD or TDD, we’ll again shy away from theoretical discussions about what is conceptually the best paradigm and just dig in - playing with the code and seeing what works and what doesn’t. By the end of it you’ll have a good idea of the freedom you’ve got with testing - leaving it up to you to choose the pattern or process that fits your style, or the style of your team and project the best.

Getting Paths for Files in NUnit Tests

Thu, 02 May 2013 05:22:45 +0000

When using NUnit, sometimes you will want to access files in the test project. These might be xml files with data, assembly references or whatever. Now typically, NUnit will actually copy the files it thinks it needs into a temporary location. This causes the problem that you can then do things like use a relative path to get files in the project. You can use manifest resource streams but sometimes this just isn’t suitable.

To get the path of the root of your test project, you can use the snippet below. Make sure you call it in a unit test fixture that’s actually in your test project, not from a class referenced in another project!

This class, ‘TestHelper’ can be included in a Unit Test project to let you quickly get the path to the test project.

[code lang=“csharp”]public static class TestHelper { public static string GetTestsPath() { return Path.GetDirectoryName(Assembly.GetExecutingAssembly().CodeBase).Replace(@"file:", string.Empty); } }[/code]

Unit Testing on dwmkerr.com

Introducing Practical AngularJS

Getting Paths for Files in NUnit Tests