At ngEurope, Julie Ralph and Chirayu Krishnappa gave an interesting presentation on Protractor. Protractor is a framework for end-to-end testing. The goal was not unit testing, because unit testing won’t catch everything. Like so many of the projects in the Angular and javascript space, it is heavily under development, but the 1.0 release is planned for July 2015. Protractor is implemented in NodeJS so you can write your tests in javascript. The most common way to run them is to

Ouch, pained my brain over this one for the last half hour or so, but finally found the solution. I had a call similar to: repository .Stub(x => x.TryGet(<Specification>.Matches(y => y.Something), Arg<Customer>.Out(customerToReturn).Dummy)) .Return(true); Because my first argument had a fairly large Matches call (it’s simplified here), I refactored it to: var specification = Arg<Specification>.Matches(y => y.Something); repository .Stub(x => x.TryGet(specification, out Arg<Customer>.Out(customerToReturn).Dummy)) .Return(true); Ah, much more readable! Only, it didn’t work. The exception I got was: Use Arg<T> ONLY within

If you’re testing your javascript with QUnit, you’ll probably run into the case where you need to initialize variables, objects, … before every test. You’ll want to run every test with the same baseline. In NUnit, you can use the SetUp attribute for this. In QUnit, it’s a little different, but nothing too hard.With the module function, you can group tests and have them run a function before starting each test. The module requires at least a string containing the

Test-driven development has become fairly standard (although not everywhere, and tests aren’t always written first). So, when we set out to build our applications and their features, we dutifully write our tests, run them everytime, yadda-yadda-yadda. Then, when we decide to add some javascript goodness to our web apps, so they feel like native apps, we … sort of end up with giant js-files full of unmaintainable javascript badness. Just like unit tests can drive your design decisions, and help

Someone once said something like: “Code is written once and read many times”. That is why I propose not to use RhinoMocks’ AssertWasCalled method for methods that accept parameters. Sure, it’s written faster than using GetArgumentsForCallsMadeOn, but check out the error message you get for this: var expectedMessage = “RhinoMocks baby!”; var actualMessage = “RhinoMocks dude!”; var fooMock = MockRepository.GenerateMock(); fooMock.Bar(actualMessage); fooMock.AssertWasCalled(x => x.Bar(expectedMessage)); Your test will fail with the following message: IFoo.Bar(“RhinoMocks baby!”); Expected #1, Actual #0. To fix

After having applied TDD for several years now, and after having assumed my colleagues do the same, I have been surprised lately to hear how many developers write their tests after their code. Test-driven development is meant to be: Write a test See that it fails (and fails correctly) Write your code See that your test passes Refactor (and see that your test and all others still pass) This has led to the well-known (for some) red-green-refactor adage. If you