Close

testing

ngEurope: Protractor

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 […]

Read More

RhinoMocks and Use Arg T only within a mock method call while recording exception

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 => […]

Read More

Unittesting javascript with QUnit

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, […]

Read More

RhinoMock AssertWasCalled vs GetArgumentsForCallsMadeOn

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 […]

Read More

When do you write your tests?

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 […]

Read More

Small unit testing tip

When asserting the content of collections, lists, dictionaries,… in unit tests, don’t do this: Assert.That(this.result.Contains(this.expectedResult1)); Assert.That(this.result.Contains(this.expectedResult2));   Or this: Assert.AreEqual(this.expectedResult1, this.result[0]); Assert.AreEqual(this.expectedResult2, this.result[1]); What if you implemented your method wrong, and the result contains more than two elements? Unless you’re totally not interested in the size of the result, always check if the collection is […]

Read More

Testing your code

Thinking about it, the team I work in has quite a lot of ‘security checkpoints’ for our code. We try to put as many pieces of code under unit test. However, we are often hindered by an old framework that can be described as a sort of ‘CSLA meets Active Record’. If unittests are impossible, […]

Read More