phawk.co.uk

Automating your tests

pete@phawk.co.uk (Pete Hawkins) — Tue, 08 Jan 2013 22:58:31 +0000

Having a test suite is awesome, doing TDD is awesome too, but what if you make that really quick change and forget to run those tests? Its likely to blow up in your face.

Don't fret automating tests is simple

I'm going to show you two super easy ways to automate your node.js mocha tests from the last post.

Git pre-commit hook

You've got to commit your code before you can deploy it, so a pre-commit hook will ensure your tests are always run, there is no forgetting.

Setting up a git pre-commit hook is super easy, first create a pre-commit file in your my-project/.git/hooks/ directory and make it executable, then add make test the command to be run on pre-commit. (Run these commands at the root of your git repository)

touch .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
echo "make test" > .git/hooks/pre-commit

Once you have this file, git will run the commands inside it and listen to the exit codes of the programs to see if it will proceed with the commit or not. Our make test from the last post will output an exit code 1 (which is an error) if the tests fail and a 0 (which is a pass) if the tests pass.

Failing tests

If the tests fail git will not even commit the code, it will leave the changes in the staging area.

Passing tests

If the tests pass your commit will go through like normal

Travis CI

You are now covered with the pre-commit hook above, git won't let you check in code that doesn't pass the tests, this next step will also allow you to see contributors or team members code is passing before accepting pull requests.

Failing travis pull request

Passing travis pull request

Integrating with travis-ci is free for open source projects and is a perfect first pass for your pull requests.

Create a .travis.yml file in the root of your repository and set its content to the following:
```
language: node_js
node_js: 0.8
```
A lot more configuration options can be set in this file, this is all we need to get our node tests running though since they follow a lot of the node conventions (like running with npm test and installing dependencies with npm install).
Signin to travis-ci with your github account and turn the tests on for your repository.
(optional) It is nice to show the consumers of your project the build status to give a little peace of mind, you can put a status image into your readme
```
Image url:
https://travis-ci.org/[Organisation]/[Repository].png?branch=master
```

Wrapping up

With git pre-commit hooks and continuous integration systems like travis-ci it is extremely straightforward to ensure you, your team or collaborators never commit or accept failing code.

It is a little more complex to get travis to run your web browser based tests for mocha in a headless browser, I will leave that for another post.

Testing node.js apps with mocha

pete@phawk.co.uk (Pete Hawkins) — Sun, 06 Jan 2013 17:16:52 +0000

A couple of days ago I wrote an article on Testing Backbone.js with mocha, this was a primer on doing TDD in one of the easiest environments possible, all you needed to get started was a web browser. If you have never done TDD before, I'd recommend checking out that post first.

For those of us who aren't building client side and are working with multi-page websites this won't be as useful, but we can reuse the same language and testing framework, mocha, on the server side with node.js.

Setup

This isn't quite as simple as downloading a zip file in my last article...

Make sure you have node.js and npm installed. Hit up nodejs.org and click the big install button.
Create a new directory for your project
Make a package.json file and fill it with the following content

Install your dependencies with npm install. I haven't used the devDependencies section for these as there are still a few problems with that and circular references when installing chai or expect.js alongside mocha.
Create a Makefile so you can run make test to run all of the command line arguments passed to mocha in an easy manner, I found this helpful from Brian Stoners article on testing with node.

Warning if you get the following error when running make test: Makefile:13: *** missing separator (did you mean TAB instead of 8 spaces?). Stop., you need to use tabs as the separator in a Makefile, spaces won't work.

Create a test/ directory in the app root — mocha will automatically look into this folder for tests to run.

What we are going to do

We need to write a Bank Account Object for our application, we're going to test drive the design of it.

The most simple test

Let's test for the existence of our bank account, that is the simplest test we could write.

Create a new file named bank-account.test.js inside your test/ directory:

You'll notice this test is pending and won't actually assert anything yet, but this is a good time to run make test and check that mocha is running as it should, if all is working you'll see the following output:

Hopefully you're all setup and good to go, if you have any problems at this stage go back over the steps, or post in the comments with any problems.

Writing the test

Now let's fill in that pending test to make it fail and give us some work to do:

Run the tests with make test and you should get a big scary error: Error: Cannot find module '../lib/bank-account'.

Let's fix this one by making our Account module.

Create a lib/ folder in the root directory of our application.
Create a bank-account.js file inside the lib folder you just created.

Re-run make test, all should fail, but it will look a lot prettier and also be red.

Making it pass

Our test uses an instantiated version of our object, therefore our bank account module will need to return a constructor function that will return an object, let's create this barebones object.

The output of your make test should now be 1 test complete and all green.

The balanace

What good is a bank account without a balance, we want to have private variables (encapsulation) via closures on this bank account object to prevent people tampering with it, so we want a method to fetch the balance, we'll also start the balance off at 0 so we know what to assert.

Writing the test

Watch it fail, you should get a TypeError: TypeError: Object [object Object] has no method 'getBalance'.

Making it pass

All should now be green and you should have two passing tests

Logding money

What good is a bank account with no money in it, lets make a lodge method on the account to input some money.

Red

We add a new suite just below the second test, suites can be infinitely nested and help to provide context in your test ouput.

Green

You are on your own here, make this test pass. If you do run into trouble, you can view the complete source code of my solution on GitHub, try not to use it though.

Multiple bank accounts

Is it just me or do you have a sneaky suspicion the variable for balance will be shared across all accounts? Let's write a new test to make sure they work.

Run your test and see what happens.

Oh dear, now our balance isn't coming out as 110 for account 1, it is coming out as 305, why could this be? Well if we add up all of the money we have lodged it adds up to 305, so it would seem as anticipated our balance variable is actually shared between all of our accounts. This has been a common mistake for me in the past with node and I'm sure might affect other people starting out as well.

What has gone wrong? Well we have reference to one Account variable, which shares one instance of the closure to var balance. Let's change our Account around a little and make its creation happen with a function. Update our test suite first.

Change all instances of new Account() in our test suite to be Account.create(). Run the tests again and see all of them fail.

Making it pass

We need our module to have export create method that will have it's own internal closure state and create our Account object for us and return it.

Withdrawing money

Now we want to be able to take out some of our well deserved cash at an ATM. Let's write a failing test.

You should get an error: TypeError: Object [object Object] has no method 'withdraw'. Let's add a withdraw method to the prototype of our Account object that let's you take out money and passes this test.

Starting balance of an account

One last thing we are going to write a test for: Allow passing of a starting account balance when opening the account with Account.create(150);.

Passing the test is pretty easy too:

Homework

If you want to continue on with TDD in node, there are a few things you can do to improve your bank account:

Type checking on all inputs into methods.
Make sure you can't lodge negative amounts of money or 0.
Make sure you can't withdraw negative amounts of money or 0.
Support for an overdraft facility.

Source

If you want to view the finished source of my example, it is available on GitHub.

Testing Backbone.js with mocha

pete@phawk.co.uk (Pete Hawkins) — Fri, 04 Jan 2013 14:03:18 +0000

This is a zero setup quick starter to using TDD, it should take about 20minutes of your time max!

Client side is one of the best places to get started with TDD as it will teach you the fundamentals without you having to worry about mocking out databases and file i/o. JavaScripts awesome flexibility helps a lot too, no matter the state of your application you will probably still find it relatively easy to get legacy code into a test harness.

Setup

I'm going to skip past the setup phase here and give you a zip file thats good to go. For the purpose of this tutorial I want to teach some TDD by example, not module loading with AMD or CommonJS, so we're just going to use namespacing to organise the application.

Structure

All source files go into the src directory, you can see an example in src/models/user.js and it's related test is mirrored in tests/models/user.test.js.

The src/app.js file sets up an extremely basic namespace of app.models, app.views and app.collections to organise our source files.

All source files are wrapped in immediately executing anonymous functions to prevent hammering the global namespace with variables.

The first task

We want our User model to use the first and last name of the user but we want a convenience method to call to get the full name of a user.

Red (the first failing test)

In TDD we always start with a failing test, how else could we be confident that our code passes the test without first making sure that it fails.

Let's write a test in tests/models/user.test.js (this file has already been setup for you as a reference). Place the test below the pre-existing test inside the suite block.

I like to start off with the most simple test that I could possibly assert, in this case it's probably to test for the presence of a 'getFullName' method.

Open up the tests/test-runner.html file in your browser, you should see this output:

The expect code is part of the chaijs assertion library, they have a few different styles of assertions, we'll continue to use the expect style throughout this tutorial.

Making the test green

The next step is to take this failing test and write the minimum amount of code to make it pass, don't write any extra code, you should have more failing tests for that.

So to pass this test we simply need to add a 'getFullName' method to the User model, go ahead and open up src/models/user.js and add in the new method, it should look like this:

Refresh your test-runner.html file and watch the test pass. The TDD three step process is red, green, refactor, given the simplicity of what we have just done and the rest of this tutorial I doubt we'll use the refactoring step, but this is a critical step in TDD.

Testing this method actually works

As you can see in the setup() method inside tests/models/user.test.js we have setup a user model with a first_name and last_name property, we want to test that those come out as 'Jimmy Wilson'. Write our next test like so and watch it fail:

You might think of writing some code here to make sure to trim the full name, but remember what I said above write the minimum code to pass the test, if you think you should add in a trim() function around the returned name, write a test for it and then add the code. For now the simplest way of passing this test legitimately would be to take the first_name and last_name properties and concatenate them with a space in between, so that's what we shall do.

Again, watch it pass and we can move on. You want to move from failing to passing tests as quickly as possible, some experts on the topic would say around 30 seconds to 1 minute maximum, I would be a little bit more liberal than that, but I would feel uncomfortable if I didn't have my test passing within 5minutes of watching it fail.

Overall in Backbone, models are quite straightforward to test until you come to mocking out AJAX requests, I'll write another post on that soon.

Testing Backbone views

We need a profile view that will display the users details.

Your test suite should run very fast and we should always mock out things like databases, file system calls or even the DOM. For Backbone this is quite esay, we are still going to use the jQuery elements, but detatched ones in memory, this keeps things very fast.

The first failing test

Create the most simple test possible, that the user profile view exists. We also need to make a new test file tests/views/profile.test.js and add two script tags to our test-runner.html file:

Add <script src="../src/views/profile.js"></script> to the source files section
Add <script src="views/profile.test.js"></script> to the tests section

And then write our test:

Pay attention to the comments in the above test file as they explain a little more about writing testable code. Watch the test fail, you should see an error like this:

We are getting this error because we haven't defined our view yet, create the file src/views/profile.js and add the following Backbone view code:

Now run your test again and it will pass.

Test View rendering

Our view template will look like this:

Before we write out failing view tests, a word of warning. Coupling your tests directly to implementation makes them brittle.

Brittle tests don't provide much in the area of refactoring and aren't that valuable. When testing the view I simple want to test that it took the data from the model and rendered, so I am going to take the HTML that the view generated and assert that it has a couple of the users details in it, not that it has an <h1> or a <p> tag.

Now watch the test fail and write the code to pass it.

As you can see my "template" is pretty ugly and should be in an external file, see the Homework section below.

Homework

Safe refactoring is one of the top benefits of TDD. Take the aweful template in the view and change it around to be a client side template of your choice, if you are not sure which I'd recommend looking at Handlebars. Use your tests to make sure it all still works.

Other resources

I'll try to write more JavaScript TDD posts soon, in the meantime checkout some of these great articles and resources that helped me learn TDD.

Testing Backbone with Jasmine and sinon - Jim Newbury who I got to meet and chat with at one of our typecast parties this year has an excellent 3 part series on testing backbone.
Testing backbone best practises - Oracle involver
Testing backbone with Qunit and sinon - Addy osmani
Testing socket.io with mocha - This will give you an introduction to using mocha to test node.js code.

Architecture process

pete@phawk.co.uk (Pete Hawkins) — Thu, 03 Jan 2013 18:24:48 +0000

I've long wanted to jot down the elements to my architecture process so that I could measure and improve upon it. I think once you have something nailed down as a specific process you can really see where the weaknesses are and make big improvements to your workflow.

Architecture for me has long been a black art of kinds that different problems need different styles of process to solve them, I doubt this is true, and it's probably just that I've never solidified my process, I'm going to try that with an example problem and note down what I am doing.

The problem

We have some friends who are amazing at JavaScript, but don't know the first thing about HTML or CSS and they want to build an app that lives in the browser. They want to draw and position rectangles and colour them in. We need a JavaScript object that will hide the complexities of the DOM but allow us to do the following:

Create a rectangle
Set its width and height in pixels
Position its x and y coordinates in pixels
Choose it's colour
Show / Hide the rectangle
Oh and of course, it only needs to work in google chrome (no cross browser testing for me).

View my solution on GitHub.

Can it be smaller?

This should be on your mind before you build anything, can it be broken into smaller tasks? If so, stop right where you are, break it down into smaller tasks and architect each of those instead.

I'd also as part of this inital descision ask, Can it be abstracted and more reusable? In this instance I would say so, howver to keep this short we aren't going to dive into creating a Shape object that Rect can inherit from, I might do that some other time.

1. Design the public API

One of the first things I like to do when architecting code that is to be used by others (nearly all the code I write is, and so is yours!) is to jot down the public API I would like to use. This gives no thought to the internal architecture, but building from outside in will help you define a suitable API. This is how I would like to use the Rectangle:

I'd be reasonably happy to use an API like this. Once I am happy with the API design I'll move on.

2. What are the responsibilities of this object?

This is where you define how the internals of the object operate, what does it need to do:

Contains an HTMLElement object
Sets CSS styling properties on the HTMLElement
Inserts the HTMLElement to the DOM
Detatches the HTMLElement from the DOM

3. Dependency diagram

I've found drawing diagrams is a great way to help you focus and think when architecting. I always find it too easy to write a couple of paragraphs about something without actually doing much thinking. Once you have to draw a diagram you will realise you have a lot more work to do.

So this simply illustrates the depency upon the browsers document API, document.createElement etc. And the realisation that the object needs to store an internal HTMLElement. This one seems quite simple, as part of a larger application it is always good to show where your object sits within the system, these diagrams help me with that decision.

4. Flow diagrams

In the interest of brevity I am going to illustrate just one flow here, creation of a new Rect object.

This may seem simple for this scenario, but it can really help simplify your solutions for more complex problems, thinking about these things up front is key.

5. Write your first failing test

Get stuck in, if your task is as small as this one it's time to write a failing test and start to test-drive your solution. If you don't do TDD yet, it's time you tried it! Have a look at my tests for Rect and see if it makes any sense.

I have all of the source and tests for this solution on GitHub.

Solution

I'd love to hear your thoughts and suggestions in the comments.

Module loading

pete@phawk.co.uk (Pete Hawkins) — Wed, 02 Jan 2013 16:16:45 +0000

So as I mentioned in my goals for 2013 I am working on a JavaScript framework, it has been really interesting so far and I am learning quite a lot from it.

One of the things I wanted was to allow the library to be loaded in any of the 3 major environments, AMD, CommonJS or directly in the browser as a global. I've done a bit of tinkering and come up with my first iteration of loading.

I hate having the dependencies hard-coded for AMD and CommonJS and will hopefully find a much nicer way of doing that, maybe it's a sign though that I shouldn't be building it as a strict dependency on the framework itself. I'd love to allow people to easily use zepto as an alternative, or even something without the jQuery syntax altogether. Maybe a more modular approach is needed as an adapter interface.

Although this post isn't about dependencies per-say, I'd love to hear thoughts on them in the comments. Also if you have a neater way of doing the loading do let me know!

Going forward, plans for 2013

pete@phawk.co.uk (Pete Hawkins) — Mon, 31 Dec 2012 12:53:37 +0000

So I have reviewed my progress for 2012, the first thing I have failed at is setting valuable goals. The biggest thing I took away from 2011 was focus, so it made made sense to me to set goals to focus on, however the taking away from 2012 would have to be value. Value is a difficult thing to set your head around at first, but I have found reading up on lean production and lean software development to help a lot.

In 2013…

I want to get my JavaScript framework (you will hear more about this in the coming months) to MVP and get it released publicly.

Breaking this down

As any software engineer knows taking a big task and breaking it down is key to accomplishing easily digestible jobs.

Finish off immediate implementation
Finish off a few applications with the framework myself
Tweak and adjust implementation to suit my needs
Refine documentation
Create a public website
Get v0.1 released publicly
Build example applications
Promote the framework
Increase uptake while taking on user feedback
Build and sell traction and value

This seems like a lot of work, and I hope there is a lot of room for learning in this process, I also think I'll be much better equipped this time next year to review this goal and write a much better wrap up of what I have learned in 2013.

Wrapping up 2012

pete@phawk.co.uk (Pete Hawkins) — Mon, 31 Dec 2012 12:31:56 +0000

Going back to my post at the beginning of 2012 when I set out goals for the first time, it has now reached the end of 2012 and it's time to review my progress.

Contribute to open source projects

This hasn't gone anywhere nearly as well as I would have liked. I have maybe had about 10 pull requests accepted over the year, all of which have been reasonably small (less than 5-10 lines changed). It is a start though and I have been working on my own JavaScript framework for a while now, but that may be a few more months before it gets released publicly as I am building applications with it to funnel the direction a few tricky areas are going to go in. Overall I am going to try more often to open source modular things I have built and try to contribute bug fixes and improvements to the libraries I use.

Write at least 2 quality blog posts per month

This has been a massive failure, it is probably a crazy goal, quality blog posts are going to take a lot more time for a writer as bad as myself, trying to do two a month in a short amount of time is never going to work.

I think going forward I will write more often, at least every couple of days and then I hope the quality will improve over time with practise.

Building apps

Launch and validate 2 apps
Build a native iPhone or Mac app and have it in the app store
Build either a native android or windows phone app and have it in the marketplace

These three goals are kind of stupid. Don't even think about launching two apps without first having a great business or product ideas, or at least something tangibly useful.

In the course of 2012 I have worked on several apps though, but this didn't come from me trying to meet this goal, it came naturually like it should have all along.

The main attraction of the year was Hedgeho.gg, an content platform to make it easier to create and discover professional content, this took the majority of my app building time and has taught me a lot.

In terms of building for the various platforms I have gathered experience with the Mac and iOS ecosystems, and have found out that the mac apps, particularly UI interfaces are about 10 years behind the iOS experience. I still haven't touched android and barely scratched the surface of windows phone, but will concentrate on business more in the future, rather than on platforms.

I've another post coming shortly outlining what I'll be focusing on in 2013.

The end.

Backbone.js conventions (part 1)

pete@phawk.co.uk (Pete Hawkins) — Sun, 09 Dec 2012 20:14:18 +0000

Backbone.js is a very popular client side framework, it is very flexible and thus has many different ways of doing things. I've found so many different examples on the web of how to do things in backbone, this makes it very difficult for beginners to know which is the right convention to follow.

I want to share some of the common conventions I've picked up along the way and why I use them.

1. Event aggregator

Creating a global event system is a great way to handle decoupled messaging within your applications. You can pass this single event instance to all of your views / components and it allows a platform for evented communication.

2. Dependency inversion of el

The this.el element within the Backbone views can easily be passed in using a common technique called Inversion of Control. This allows us to do flexible things when testing our views:

Testing views we can pass in an in-memory DOM node $('<div>')
We can use in memory nodes on list views to build up list items and then only append once to the actual DOM.

3. Unbinding events

This one is major, especially if you are coming from a server side garbage collected language where it's trickier to get memory leaks. With Backbone you have to cleanup all of your own events when you remove a view.

I put a destroy method into views for this purpose, I ensure all of my views define this method and cleanup any custom bound events.

Looking through the Backbone source code you will see views have a dispose method that clears up any events bound by the view onto a model or collection held within it, it also automatically undelegates all events bound in the events hash. This happens when you call .remove on a Backbone view.

Wrapping up

I hope to present another one of these informative posts soon, if there is anything in particular you would like to know how to handle in Backbone, please drop a comment below. Again these are just things I have come across and find work well when building maintainable Backbone apps, if you have any better takes on the above, drop a comment, I'd love to hear about them.

Don't ever fix a bug

pete@phawk.co.uk (Pete Hawkins) — Sat, 03 Nov 2012 10:50:00 +0000

We'll start by a basic definition of a bug.

A software bug is an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.

What generally causes a bug

In my opinion bugs are caused by complexity, complicated code that hasn't been designed effectively to make it as simple as possible.

There are code smells that you can tell simply by looking at code to know that it is complex and will potentially be bug prone.

Long methods (methods with 20+ lines of code)
Long classes with more than a couple of hundred lines of code
Many nested control structures
In JavaScript particularly code that has many nested callbacks

Don't take it for granted that these things ensure you will have code ridelled with bugs, but in my experience, the likely hood is high.

What does a bug fix look like

In most cases especially dealign with the type of code mentioned above a bug fix is generally adding more control structures or input checks, this is not necessarily a bad thing if these checks where missing in the first place.

However, if we already had the appropriate checks for input coming from users or third parties and the bug arrised from within our own application a bug fix often leads to more complexity and longer methods.

Under the pressures of delivering we often succome to this kind of fix, a temporary hack around the real problem. Now that we know what the real problem is (ineffective design) we can approach it in a different way.

What is the alternative

The alternative that I personally propose is refactoring. Patching up bugs will only get you so far and the likelyhood it will lead to more issues is high. Don't ever fix a bug, refactor it out.

Simplicity is the goal, taking complicated problems and coming up with simple, well composed solutions, taking code as mentioned above with long methods and lots of controls structures and simplifying it, the goal:

Short methods that do one thing and one thing only
Well composed classes that deal with one concern
Simple control structures
And in JavaScript, not having many nested callbacks

I personally practise TDD and find that it helps to drive the design of the code you write to have well composed short methods, especially because you think a lot more about the design of the code up front and thinking about writing a test focusses you on solving one problem at a time.

I know TDD isn't for everyone, but I'd really encourage you to try it if you haven't and give it a couple of weeks to enlighten you, regardless, I hope you can see the benefits in refactoring bugs away.

Making things

pete@phawk.co.uk (Pete Hawkins) — Sat, 29 Sep 2012 17:57:00 +0000

If I were to put a label on myself within the category of engineer, that would be "technologist". I love researching and playing with the latest technologies, one of the downsides to this is that I don't get much live. I put a lot of time into learning and staying up to date, but if I were to list the products I have made lately, they could be counted on one hand.

I recently found myself looking at HTML5 AppCache, and thinking I NEED to make something using this. I caught myself on a few days later and realised how absurd this sounded, I wanted to use a technical solution to solve a problem in a non-existent idea. I need to cut this attitude out and start looking for problems to solve before even thinking about solutions.

I am learning that being a maker is much more than being a good engineer / designer and knowing the tools. Even having a good sense of business and knowledge of the industry is not enough. You need a desire to build, a will to deploy. Getting your apps or projects you tinker with on your machine onto the web for others to see or use should be a strong motivation for me, but so far I keep getting distracted. I complete 80% of one thing and I am onto the next new tech or next thing I want to play with.

From here on in, I am going to try and make things. Not simply code up something and leave it lying dorment, but build, market and test products, not because it's a new piece of tech I want to use, but because it genuinely solves a problem, or at least attempts to.

Note: Evidently I did get to use AppCache in a product, napkin.io, a simple app for creating throwaway notes that @armstrong and I have been tinkering with.

Modular client-side development

pete@phawk.co.uk (Pete Hawkins) — Sun, 19 Aug 2012 13:19:00 +0000

From using node.js and sinatra quite a lot in the past few months it has really been evident that our client side JavaScript code and loaders don't seem to deal with the modular concept very easily. I have spent the past few weeks building modules or micro applications that form a piece of a bigger puzzle. Reading through TJ's post on components at the end of last week and how the guys at learn boost have pretty much built their entire application based on this concept was comforting and you should definitely give it a read!

Philosophy

One of the most important things I have found is writing your module outside of your application, this ensures a couple of things:

Your tests are completely isolated
Adding a dependency to your module is a pain!
Your module can be easily re-used, just drag and drop it into another app

One of the most important things to take from this is coupling to a dependency is hard, it really forces you to think if that dependency is necessary and you will end up with code that has very loose coupling, which is always a good thing!

To demonstrate how easy it is to move your code to another application, this source code I put together for this app was already in an app I was developing last week. It took all of about 5 minutes to piece together the sample code.

Walkthrough

The sample code is available on GitHub. If you are running this code you will need to set up a server in the root directory to make sure all of the assets are loaded in. I was lazy and just useds PHP 5.4's built in server:

$ php -S localhost:8000

File structure

Inside the root js folder we have a modules directory and one extremely small module action-dialog. Keeping all of your modules files: Views, Models, Collections and assets separate really makes things reusable. It will also help in a large team and help avoid people changing the same code at the same time.

Tests

With this modular approach, each module should have their own tests, take a look at the modules/action-dialog/specs directory.

For running the tests I have been using one tests.html file in the root of the application. For me this approach just minimises the code taken to get a test runner up and going. With mocha it is really easy to still drill down and just view the tests for one particular module during development, just click on the Action Dialog View heading and mocha will only run that spec.

Assets

I agree with TJ in his components article that each module should have it's own CSS and images, he adds that the CSS should only be structural CSS for layout, and not delve into typography or colour at all. Your applications independent CSS in css/layout.css should be like a theme that covers all of those reusable style attributes.

Also images and html should all be self contained in the module, currently I load in the HTML with the requirejs text plugin and compile it into a template using Handlebars. Images can easily be placed into the modules CSS and then loaded into the core application that way, or referenced via the modules HTML templates.

Core Libraries

So for my applications I have several core libraries that I always make use of:

In this example and in the applications I am building currently, these core libraries sit in /js/libs and are shared between all of the modules. This does go a little against the modules being completely standalone, but it would be simple enough for a module to have its own libs folder and manage its own library dependencies. If a new team member comes on board and doesn't like using mochas BDD style specs they could certainly write their own Qunit tests for their module and have it run those independently of the rest of the app.

main.js

To simplify loading the modules into the app, each module has its own main.js file in the root of that module. This is just a convention for that module to export whatever public API is needed to run.

Documentation

Each module should have its own readme file that explains how it can be used and go into detail on its public API and events.

Loading

Require js is used currently to load the modules into the app, and load their specs in and run them. While I like require JS a lot, I feel something else out there is required to make this modular approach even better. I want my loader to pull in CSS and assets as well as JavaScript. I have looked at various client side module loaders and haven't found any that solve this problem well yet. Jam and bpm seem to be the nicest loaders out there at present, but are really geared towards loading in external open source modules rather than your own custom modules living in the file system.

A build script using grunt or similar could solve this problem and over the next month or two I'm sure I will either find an excellent tool for this job, or try to write one.

Conclusion

I am going to continue with this approach of building micro applications and glueing them together to form a large application. I have been very impressed so far by this approach, and for me it has made my code extremely lean.

I'd love to hear more thoughts on potential problems with this, or anyone else using this approach and has any suggestions. Hit me up on twitter or GitHub.

Trying BDD

pete@phawk.co.uk (Pete Hawkins) — Sat, 07 Jul 2012 19:02:00 +0000

When I started out as a developer and to this day I am always seeking ways to improve my workflow and the quality of the code I write.

Before I started writing tests I would still try and do top down design, looking at the end goals, writing down the behaviors as comments in files before I would write the code to complete the task at hand.

This approach certainly works well, although was just covering one advantage brought from top down design, thinking. Thinking before you code is absolutely neccessary, but as developers we need more than that, we should have confidence in our code and be able to safely refactor and improve our codebase at any point in time, without having to worry about extensive manual testing.

Starting out with tests

I've started to use behaviour driven development (BDD) as a major part of my workflow, definng business rules (behaviours) along with the design of each feature up front. Tests (or specs) should be based on these behaviours and entirely separated from the implementation used to pass them, making our specs extremely valuable for us devs and for the business people too.

I am still very much new to this BDD thing, and missing out on a few key parts of BDD as a whole, sticking initially to unit test specs and the core language for describing behaviour (scenarios and given, when, then).

I try to write stubs for all of my behaviours up front without writing any test code. Once I have this structure set up I can then start writing my first test specification, moving quickly on to writing the code to pass that spec, this schedule should follow a strict pattern.

Red, Green, Refactor

write a test spec to assert one behaviour
run the test and see it fail (red)
write the minimum code to pass the test
run the test and see it pass (green)
refactor the code so you are happy that it is readable and easily maintainable
run the test again to ensure you refactored code passes
repeat until you are happy with the refactored code

These steps should be done in very quick succession, 30seconds to 2minutes. I think it is ok to take longer depending on the complexity of the job at hand, but aim to make this progress as quick as possible so everything is fresh in your head. Another byproduct of quick progression ensures you won't have massive amounts of code tested by just one spec, you will end up having better test coverage.

Hopefully this gives you an overview of the advantages and process to using TDD / BDD as a methodology for development. The main enviornment I am working in right now is JavaScript in the browser and on node.js, I will put together an article specifically on how I acomplish testing JavaScript and the tools I use (for now listed below).

If you have any tips or anything to add please feel free to comment.

2012 is full of goals

pete@phawk.co.uk (Pete Hawkins) — Sun, 15 Jan 2012 11:24:00 +0000

As this is the first time setting goals to measure myself against next year, I don't really have anything tangible to measure against from the start of 2011.

The one thing I have accomplished though is getting a lot more into development. I started out from an early age as a web designer, got around 5 years commercial experience under my belt and then in mid 2010 after starting a fantastic job at Crafty Devil I started to learn more about development, starting with PHP and Codeigniter.

I enjoyed every minute writing code, even though my code wasn't anything special for the first 3-6months. Slowly I started to realise my passion for design disipating, I was growing rapidly in love with coding. I still have a strong appreciation for great design and tasty looking apps, but my heart has changed, I now can't wait to grab the laptop and learn something new about programming, systems or performance, gone are the days spent culminating over single pixel adjustments in photoshop and moving grid lines a few micro pixels in illustrator.

I think I possibly should have been a developer all along, I always struggled profusely with artistic creativity and really treated design as a logical process, which is why most of my designs probably lacked that delight factor all these years. Through education my strong points where always math, ICT, business and accounting which makes sense why I enjoy figuring out how things work and taking complex problems and coming up with an efficient solution.

Summing up 2011

The past year has been a very educational one for me, learning new things daily and vastly growing my skills as a developer. I have got a real passion for what I do and always striving to learn more.

It has been a great help to be surrounded by other talented and wise developers both in Crafty Devil and in the local community, to provide help, alternate solutions and share articles, thoughts and ideas. I love this industry!

Looking forward

Without setting realistic goals, next year I'll have nothing to measure my personal progress against. I have never made any resolutions or long term personal goals before, soon to be 25, I think it's time I started.

The goals I have for 2012 are reasonably specific, and I'll explain them in a little more detail below.

Contribute to open source projects
Write at least 2 quality blog posts per month
Launch and validate 2 apps
Build a native iPhone or Mac app and have it in the app store
Build either a native android or windows phone app and have it in the marketplace

Contribute to open source projects

In my day to day work I use a ridiculously high amount of open source software, and up until two weeks ago, I have never contributed anything to an open source project. Sure I've shared a fair amount of code on Github, but never contributed to a larger scale, more widely used project.

I've had this goal in mind for some time, but never measured against it, hopefully this will give me the push I need to make progress.

Last week I finally made my first public pull request on GitHub to a Pagination module for Play Framework. I'm definitely not bragging about this, the only 1 word that changed in the diff was a css class in the view file, but it's a start, a very small start which gave me a bit of a moral boost getting that first pull request accepted.

Hopefully I'll continue to contribute more to projects that I actively use, such as Codeigniter and Play Framework.

Write at least two quality blog posts a month

This goal doesn't look too hard to accomplish, but the main problem I always struggle with here is quality. I'll spend an hour writing a draft post and 10minutes later after a rapid spell check, it's live on my blog. I then have another read and find some phrase of text that barely translates to human readable english, then goes the mad scramble to change it round before one of my few twitter followers visits the page.

To accomplish this goal and write quality posts I know I need to set more time aside for editing, spending an hour writing a draft post is only the start.

I need to fire a few more hours towards making articles coherant. I have always struggled with writing, rushing things out because I don't enjoy reading over my own work, we'll see how this goes.

Launch and validate 2 apps

Over the past two years since I have "become" a developer I've come up with some class ideas (at least I think so anyway), started building them and for whatever reason, moved onto something else, leaving these projects stagnant.

I need to take an idea from start to finish, finish being a product launched to beta to validate whether it can work and also whether it can make money.

In 2011 I've got the closest I ever have to validation, I had a product almost ready for alpha testing, when I decided to ditch the code and rewrite it based off an API. I doubt I made the correct descision as by now I probably could have validated the idea amongst a few hundred target users.

Build a native iPhone or Mac app and have it in the app store

Having looked at Cocoa touch around 4 separate times last year, I still really want to make an iPhone or Mac app that I can launch into the app store. Sure I've launched a phone gap and appcelerator titanium iPhone app into the app store through work, though it's not quite the same as having a native app in there.

In 2011 I built my first native Mac app, it was a very basic monthly compound interest calculator for my father and really a simple primer on using Objective-C.

I didn't seem to have any problems understanding or writting Objective-C, the main issue I have is hooking the code up to the interface and making the interface do fancy stuff.

Having mainly done web development up to this point and not coming from a Computer Science university background, I've never made a desktop app, and I suppose once you get into this way of working, a lot of the knowledge will carry through to other platforms.

Build either a native android or windows phone 7 app and have it in the marketplace

I'm also very keen to look at the other side of the fence and develop either a windows phone or android application, and have something to compare against iOS and possibly consider which type of mobile app development I'd like to specialise in, if any.

I'm not sure which I'll be attracted to yet, I'm currently using Java and probably going to be using it a lot more with Play Framework, that may help with writing an android app, but I usually don't go with the easy option, so I may well get to do a bit of C# this year.

Credits

Have to credit our Crafty Devil quarterly retreat in which we were asked to think about our goals for the year and spend 5minutes talking about them. There are probably a few extra ones in here than I spoke about at the meeting, but having more time for these to lament in my mind has helped a lot as to what my goals should be.

Also have to credit Matt Swanson for posting his developer year in review, this post made me see the value in posting your goals on your blog and then being able to measure them year on year.