A while ago, I had to explain, not for the first time in my career, why using interfaces, having loosely-coupled code, and writing tests (first) is a good idea. Time and again, I find developers, teams and companies resisting certain ideas that have been around for years or even decades. One of the reasons often stated, is novelty. An idea, principle or technology is refused because it is new and who knows what the next thing will be. Better to
I always try to convince other developers that writing your test first is not just about doing TDD the “correct” way (if there even is such a thing). That sounds a little fundamentalist. Rather, it’s about making sure your test is failing and failing for the right reason. Actually, this is only one reason, as writing your test first also pushes you more towards writing only the code you need, writing tests that cover all code paths, and forcing you
When writing tests, you can often end up with tests that have (almost) the same setup. Certain input variables may change, but the structure of the setup code remains the same. When the setup is small, you can copy from one test to another. But when there is more ceremony involved, you will start to feel the need to avoid duplication. It’s a best practice to apply coding principles to both your production code and your test code. Don’t repeat
Continuing on my previous post on WebAPI, Autofac and filters, I now want to add an integration test. Unit testing WebAPI controllers is no different than testing other pieces of code. Just inject mocks in the constructor and you’re good to go. Integration testing can be as simple, if you’re not using filters. The filters can, however, add interesting behavior to your controllers, like the exception handling I explained in my previous post. To fully test this, you will have
Those who know me, know I’m a big proponent of unit testing. I try to write my tests first, but I don’t believe in absolutes. If you write your tests afterwards, at least you’re testing. But not everyone is even convinced of the value of automated tests (be it unit, integration, end-to-end). Frequently, this discussion is a pointless one, because it’s all about vague arguments and based on experience. You have to take a ride in the car (or at
A while ago, I had to introduce a developer with little experience in modern .NET development to a project I am leading. I gave the usual talks about the architecture, picked some classes to clarify, explained patterns we use, etc. But I also wrote down some basic principles that are important in the project. When I read them again, I realized they’re some core principles I find very important when coding. I know there are many principles out there to
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