Before looking at the role of code coverage, I’d like to take a few steps back and look at the objectives of testing.
When working properly with test driven development, no production code is written unless there is a failing test driving the change. As soon as the test pass, no addition of production code is allowed until there is again a failing test. If that principle is followed, there will simply be no production code that is not covered by a test.
My objective is to achieve high code quality.
My way of achieving that is TDD.
An effect of that is that I do get full code coverage.
To write an awesome pull request is not that hard, but requires a bit of planning and reading up on tools.
Add an issue describing the feature before coding. It’s an opportunity to get feedback both on the suggested feature and on how to make it fit with the existing design/architecture.
Learn git. As a minimum you need to know how to fork the main repository, create feature branches and how to rebase them on a refreshed master pulled from the main repository. Check out the contribution guidelines from Nancy for details.
Limit each pull request to a single issue/feature. It’s much easier to review and discuss multiple small focused PRs than one large complex.
So you have Resharper and found a bunch of unused usings and other things that should be cleaned up? You’re welcome to submit those non-functional changes in a separate pull request.
Run any existing tests and make sure you didn’t break anything.
Make sure your code meets the test coverage expected and coding standard in the project.
Respect the architecture of the existing code. For example in AuthServices that supports both IIS and Owin hosting, it’s not acceptable to reference System.Web from most parts of the code.
A Gift to Who?
Finally I’d like to mention the view of pull requests as gifts. I totally agree with viewing pull requests as gifts. But not only a gift from the contributor (sending the PR) to the maintainer (receiving the PR), but also from the maintainer to the contributor.
I give you this code that I have written to improve your project.
I will take care of your code by reviewing it, maintaining it and take responsibility for any bugs in it.
This post was inspired by a similar post by Mark Seemann. It’s very good (although more lenghty than this), so I recommend reading it.
Last week, I was in beautiful Oslo in Norway most of the week for NDC 2014. It was a great conference and I’d like to point out a few highlights.
For the first time, I was a speaker at a major conference. I’ve done quite a few internal talks before and a few externals too, but never at such a high profile event as NDC. Looking at the speaker list I’m really honoured to have been part of it. I think it was challenging and fun – but I also found myself much more nervous than I had anticipated.
There were so many great people at the conference (both speakers and participants), but there are some that I think stand out with exceptionally good talks.
Troy Hunt’s How I hacked my way to Norway. Troy is entertaining and educating on the same time. A talk that is both fun to listen to and that actually gives some concrete advice on how to (not) do security. I’m a bit disappointed though that he never used the IKEA allen key when hacking sites ;-).
Luke Wroblewski’s It’s a Write/Read (Mobile) Web. The keynote, which was an eye opener to me that mobile and touch devices are not only for passive consumption of material. I especially liked the count of the number of clicks required to book a hotel on the major sites (well over 100) compared to FOUR on the best one.
Scott Meyer’s Effective Modern C++. An introduction to some of the “new” features of C++11. The talk makes sense to a C# developer too – C++ developers are often far ahead of us in being aware of the details of how the language works and what the pitfalls are. Although there are more pitfalls in C++, a lot of the things Scott talked about applies to C# as well.
ASP.NET Identity is the reworked, flexible replacement for the old membership system that has been around since ASP.NET 2.0. ASP.NET Identity is more well designed and flexible than the old membership system and uses Owin middleware components for external logins such as Facebook, Google and Twitter.
Compared to the membership system, the architecture of ASP.NET Identity is very much improved and decoupled. Actually, ASP.NET identity doesn’t know (nearly) anything about Owin at all. ASP.NET Identity is working on an application ignorant level, taking care of user and role storage. Then there are the Owin authentication modules that takes care of the actual interaction with the external providers and keeping the user session. The plumping code required is built into the AccountController created by the new project wizard for ASP.NET projects.
For a typical application there will be a number of different application layers cooperating to provide the authentication functionality.
The ASP.NET Identity module sits at the very bottom of the chain, far, far away from the incoming HTTP Request. In fact, it knows nothing about Http at all.
The MVC AccountController provides all the plumbing to make the different modules interact with each other.
The Google Authentication Middleware interacts with Google to provide Google signon. In this example I only show Google, but if more social networks such as Facebook or Twitter were offered, they would be next to the Google middleware in the stack.
The MVC Acount Controller is the generated MVC controller that ties all of the layers together.
The ASP.NET Identity module handles user and secure password storage, role mapping etc.
I was recently made aware that some unit tests for Kentor.AuthServices were failing on non-English computers. To handle that, I set up an Azure VM with Swedish installed and made a special unit test that would run all other tests with different UI cultures.
When I first understood that I had tests that were broken when run on non-English computers I of course felt that it should be fixed. The tests should not only run with other languages to enable developers from other countries. The tests should of course be possible to be run and used to find problems if someone reports errors on computers having a special language installed. There’s quite a few places in the code with string formatting and it can differ with different cultures, causing hard to find problems.
What I did was to write a special unit test that finds all other unit tests in the code and runs them with different UI culture. The unit tests are found using LINQ and Reflection (it’s an awesome combination that’s extremely powerful) and then they are run with reflection.