Freitag, 11. Dezember 2015

Advanced NCrunch: Isolating tests

I am constantly amazed on how far you can push the frontiers of automated testing in order to reduce blind spots and mitigate software risks.

"" or how we started to change the company culture

For the past four months we have a weekly about mixed topics. After a colleague of mine and I started to prepare and present these talks for a couple of weeks, we found some colleagues presenting topics as well.

Donnerstag, 3. September 2015

Review: NBP116 – How to Master the Habits of Our Everyday Lives, with Gretchen Rubin

I just love the Internet because it makes expanding your horizon and knowledge increasingly easy for everyone. Each followed link may open up a new door. So let me tell you how i got here:

Mittwoch, 2. September 2015

"" or how we cheated our management

After I changed my job, I had to face the same old problem: I have to work for a project. I have to work 40 hours a week and each hour needs to be for a project.

Dienstag, 30. Juni 2015

Shipping tests along with production code

With NEdifis we advocate putting tests right beside the code rather than into separate test projects. Both approaches have its pros and cons, yet the more popular still seems to be putting tests into a separate test project, see for example Mark Seemann: Where to put unit tests or StackOverflow: Do you put unit tests in same project or another project? The most common reasons for separated test projects are:

Mittwoch, 10. Juni 2015

"To throw or not to throw": Asserting exceptions on tasks with async/await

For testing exceptional behaviour i like using FluentAssertions Invoking extensions. However, i noticed that using this with async/await seems not to be supported and requires unelegant rewriting (Please, prove me wrong on this). However, using C# 6 await in try-catch this is now very simple to do:

Mittwoch, 3. Juni 2015

Reducing repetition in native wrappers using expression bodied members

Whenever wrapping legacy or native APIs in .NET i hate the verbosity of the code that needs to be written. APIs without a concept of exceptions are often designed returning error codes which requires results to be passed back per reference. In .NET this translates to using out-Parameters.

Montag, 18. Mai 2015

C# 6 in action: Null propagation applied

Just another nice everyday example on how C# 6 can reduce verbosity. In case you don't let ReSharper teach you, be sure to spend 8 minutes on C# 6.

Samstag, 9. Mai 2015

.NET's bad relatives: On native dependencies

I have a love-hate relationship with native dependencies. As a developer i love quickly boosting my app with features from native code libraries using e.g. P/Invoke. However, when it comes to deployment we need to make sure that the native dlls will be 1) correctly deployed to the target environment and 2) correctly loaded at runtime.

Freitag, 8. Mai 2015

Yes, you can test it (1) - Prerequisites

Before you start with unit testing, you must fulfill one prerequisites ... you need to create a unit. Sounds logic, but what does this mean?

NEdifis: How we test if something got traced

Sometimes we have the requirement that something needs to be logged. Lets take some examples.
  • a csv importer gets an invalid file. Although the app can handle it, a warning should be logged.
  • an exception got caught and is not re-thrown, an error should be logged.
We use a "log4net trace listener" to get our traces logged (which is another story) so tracing and logging is technically the same for us. 

NEdifis provides an easy to use trace listener to receive all traces or logged messages. It uses the dispose pattern to register and deregister itself, therefore you need to dispose the TestTraceListener.

using (var ttl = new TestTraceListener())
    Trace.TraceError("here is a message");

    ttl.MessagesFor(TraceLevel.Error).Should().Contain("here is a message");
Fortunately, debug uses the same listener collection than tracing (but Debug has a System.Console like interface). So for debug, you can use the same trace listener and code.

using (var ttl = new TestTraceListener())
    Debug.WriteLine("nice debug");

    ttl.MessagesFor(TraceLevel.Verbose).Should().Contain("nice debug");

Keep in mind that "System.Debug" only works if you app was compiled with "Debug". For "Release" this list is empty (see unit test).

Mittwoch, 6. Mai 2015

NEdifis: How we organize our test classes

For the past decade I read a lot of articles about unit testing. There are thousands of best practices, do's, don'ts and especially workarounds. I remember a "trick" of a friend of mine who tried to find a way testing internal classes methods in a separate test project. His idea: he made these methods protected and created a derived class to wrap these methods in another internal method to access these methods from a test class. Yes, it is as complicated as it sounds.

In our project we started to add our unit tests to the same project and kept them together. This gave us the ability to keep things internal which should stay internal. After some iterations we ended up with two conventions:

  • Each test class ends with "_Should" so we can read tests easily
  • The test stays along with the class in the same namespace (folder)

The second point avoids the annoying duplication and maintenance of a folder structure or a huge namespace "Tests" with dozens of tests. In addition, you can see at a glance which classes don't have a test.

For this cross-relation, NEdifis provides two attributes for this relation.
public class TicketAttribute : Attribute

// ReSharper disable once InconsistentNaming
public class TicketAttribute_Should
This makes e.g. a navigation between these classes easier using "go to definition" and gives the opportunity for convention tests to check e.g. if each class has a test or a test fixture is properly named.

How we organize branches and releases in GitHub

After some experience with Git Flow & GitHub Flow, AppVeyor as Continous Integration tool, our OneClickBuild to simplify the build & deploy process and a bunch of other tools, we finally came up with the following workflow.

AppVeyor automatically builds and tests the master branch and publishes the package to nuget. We need to increase the (semantic) version number manually in two files (appveyor.yml and solution.targets), otherwise the publish step will fail.

Note that we switched to GitVersion which automates versioning.
Therefore we don't want to get each typo, minor pull request or a change in a readme be reversioned and published to NuGet.

So we created the develop branch as the default branch used for pull requests. If we decide to create a new version, we increase the version number and do a pull request to the master. This reduces the number of NuGet versions but we still can manage as many pull requests as we want.

Finally we use a simplified version of Git Flow but a more "complex" version of GitHub Flow. We don't create release branches in favour of pull requests. On the other hand we use a develop branch for pull requests.

Dienstag, 5. Mai 2015

GitHub: Boosting your with status badges

One great thing about web-based repository hosting services like GitHubBitBucket and others is their ability to directly render Markdown documentation as Html. Although typically used for static documentation you can easily enhance the web representation by referencing dynamic content by url.

These days, a very common practice is to include status images, also known as badges, at the top section of your to indicate current quantities and metrics related to your repository, e.g.
  • current build status (e.g. Jenkins, Travis CIAppVeyor and others),
  • package download count, total or per month (e.g. NuGet, npm, gem, etc...), 
  • code quality stats like test coverage (e.g. Coveralls) or technical debt (e.g. with SonarQube)
  • average time to close issues or accept pull requests (e.g. Issue Stats for GitHub)
This is a great and very simple way to improve the first impression of visitors and to show your professional working style.

How does it look? Head over to GitHub and explore some popular repositories. For example, i like Microsoft/TypeScript or elastic/elasticsearch-net.

Here are some badges of our own projects

Popular badge providers seem to be or

So, get badging!

Dienstag, 21. April 2015

A quick and simple, throw-away NuGet server

We are just beginning to work on a small open source lib for NuGet-powered plugin management called NuPlug. For testing purposes it would be nice to have a little, throw-away NuGet server. Since i am a big fan of vagrant and docker i did a quick search on the docker ecosystem dockerhub finding jonathanmorley/nuget. However, this is just an example of running the NuGet client within docker, not the server.

For a NuGet server, you can simply build your own. But if you want it even simpler, you can use the standalone-branch of TeamCity NuGet support. I hacked together a few files that install and start the standalone NuGet feed on mkoertgen/hello.nuget.server

Hopefully, someone will probably come up with a dockerfile that does just that.