[...]... But of course, this is testing with CoffeeScript, so we can do: describe "Basket Class", -> # individual tests go here Inside this describe block, we define individual tests like so: it "should be able to add item to basket", -> # code for testing this here These are nested, so you get something like: describe "Basket Class", -> it "should be able to add item to basket", -> # testing code Not only can... to organise tests within that one file Personally, I'm a fan of keeping things organised within multiple files The eager-eyed amongst you will realise I haven't made a spec file for my Item class We're leaving that for now, and concentrating on some basic specs for our Basket class Most tests will need some sample data to work with You might have heard of these as fixtures in other testing frameworks... progress with the development of our application Refresh the SpecRunner.html file and you should see that the first spec passes! However, just because it passes, it doesn't mean that it's complete As we continue on developing the application, we'll see issues turn up and we'll need to refactor our tests and implementation code Developing with tests is fantastic for this reason; we can easily refactor without... see the way developers get hooked on developing with tests You'll notice we haven't created any form of front end for our system yet We're not being distracted by the GUI, by aesthetics or other unimportant minutiae Thanks to our tests, we can put that to one side and concentrate solely on our application's logic In chapter two we'll continue with more testing and look at refactoring more of our code... the user is trying to take away more items than exist We'll deal with that in a second @items[item_loc].quantity -= quantity What I'd like to do is package these up within methods, and then call one of them based on the parameters passed in As these methods will not be used outside of the remove method, it makes sense just to declare them within it: remove: (item_id, quantity="all") -> return false if... look at calculating the total costs The three variants we need to check here are: 1 Calculating the cost for a single item 2 Calculating the cost for a single item with a quantity greater than 1 3 Calculating the cost for multiple items with quantities greater than 1 As you'd expect, the tests are very simple (as you'll find most tests are – any complex tests often should be split up): describe "calculating... removeQuantity = (quantity, item_loc) => @items[item_loc].quantity -= quantity Note the use of the =>, which maintains the scope of this (or @) within the removeAll and removeQuantity functions If I didn't declare the function using => and used ->, the value of this within those functions would point to the remove method, not the Basket object Our next step is to simply call removeAll if the quantity passed... item_id I can do this in full confidence; a quick rerun of the tests show they still pass I'm also not happy with this conditional: if item.quantity . Franklin EFENDI MINIBOOKS Testing with CoffeeScript Testing with CoffeeScript Copyright ©2012 Jack Franklin All rights reserved. No part of this book may be reproduced without the prior written. it a hit with developers. In this minibook, I’ll show you how to setup Jasmine as a standalone library, integrate it with CoffeeScript and build a fully functional CoffeeScript app with Behaviour. putting up with my questions to editing content I’d only got to him at the last minute, cheers. Next beer’s on me when you’re in London. Of course I couldn’t write a book on CoffeeScript without