Monthly Archives: March 2016

Logging with Serilog in .NET

A logger might be one of the most boring task to do while coding, but fortunately there is packages like Serilog that handles that for you. I don’t have that high demands for a logger, as long as it outputs my log entries where I want it and the way I want while beeing easy to use, I’m happy 🙂

Installing Serilog

The first thing you’ll need to do is add Serilog to your project with nuget.

Apart from that you will also need sinks which is not in the core package. The easiset way to find those are probably to search for Serilog in nuget package manager. The first one I will use is Serilog.Sinks.ColoredConsole.

Setup Serilog

To create a global ColoredConsole logge, this is all you need to do:

And of course, if you want a local logger:

And to actually output anything you can try this:

If you try to run this you will only see 4 of the 6 prints (Information, Warning, Error and Fatal) and this is because you have a minimum level set. The default minimum level is Information, which means that everything including and above Information will be displayed.

Output with serilog

If you want to see verbose and debug as well you need to change the minimum level, This is done when initializing the logger:

And this is the result

Output with serilog

I want more!

Usually it’s pretty useful to log the same logs to different sinks, at least one to console and one to file. And this is also pretty straight forward during initialization:

There are a log more features for serilog like

  • Sinks – Write to more places such as mail, azure, rabbitmq and more
  • Enrichers – Enrich your logs with different properties sucha as thread id
  • Filters – filter out specific entries

Conclusion

There is a lot more to do with Serilog than I have described here and if you are interested you should go to the documentation and check out what you really can do. From my perspective it does everything i want a logger to do which is log to console, file, rolling file and being able to set levels for each while at the same time being lightweight and easy to add.

 

Getting started with unit tests in C#

As a first real post, unit tests seems like a good idea since you are supposed to write unit tests before the real code. Most developers would agree that they are really great when properly maintained, but not a lot of developers really want to write them.

From my experience, projects fall in to one of three categories when it comes to unit tests.

  1. Little or no unit tests – Either they started doing tests in the beginning of the project and when the horrible deadline started getting close the just skipped the tests or the project were in panic mode from day 1 which means no tests. This will lead to project type 2.
  2. The project has been active for a good while, with little or no unit tests, and suddenly everyone wants full test coverage. This leads to a massive effort from all of the developers (or maybe some consultants) to get 100% coverage. The quality of the tests will probably be crap since only coverage counts and the tests are useless.
  3. The developers in this project has been in a type 1 or type 2 project before, so they are really motivated to write the tests before the implement the function. The coverage might not be 100%, but the quality will be top notch. Even when the deadline is getting closer they will persevere and keep writing those tests because they know that in the end, the will save a lot of time. Every now and then they will find some bugs with help from those test.

This is at least how all projects I’ve been working on could be defined.

Even though I really hate writing tests i really enjoy having them, so type 3 is the way to go. Hell, I even write tests for my personal projects every now and then.

Writing your first unit test

Project to test

First up is to create a project to test, and for today I will go with a class library. I create a project called MyLibrary with one single class called MyClass:

Nothing fancy, but it will do to demonstrate unit testing.

Test project

The next step is to create a test project. The wat to do this is just to create a new project in the same solution as MyLibrary and select “Unit Test Project” and name it. You will also need to add references to MyLibrary.

Add new "Unit Test Project"

After the project is created you need to create a new class, mine is called “TestMyClass” is just an empty class without methods.

In order for Visual Studio to find the tests, the class needs “TestClass” attribute, the methods needs a TestMethod attribute and needs to be public like this:

 

The next step is to write the actual tests. We will start with a simple test that just calls ToLower with the parameter “Foo”. If everything works like it should, we should get “foo” back.
If you have read the tutorial on unit test on MSDN you probably noticed that they use the pattern “Arrange, Act, Assert” which I find pretty intuitive.

This means that you first set upp everything, call the method to test then check the return value. For our class that means:

After you’ve added this to your test class, you run the test by going to Test -> Run -> All test. Now Visual Studio will MyLibrary and TestProject, open Test Explorer and run all tests and the result should be something like this:

Test result

When testing your code you should test all possibilities, and one of them testing for exceptions. You could of course do this by a try/catch around your method, but a more elegant solution is to add “ExpectedException” attribute to your class. In our case a test with null would look something like this:

This is two small examples of unit tests just to show you how it could be done to get you started writing your own tests. MSDN has a pretty good article series which is probably a good idea if you want to dig deeper. You can find it here.

Organizing your tests

I guess you could do any way you want, but having a clear naming convention helps you find the correct test within seconds and when a test fails, you know why immediately.

Naming classes

First off, every single class get there own test class, so if your tested class is named Foo, the name for the test class should be something like TestFoo.

Naming methods

I like to name it Mehod_Params_Result, so if the function is Add with parameters 3 and 4, the name for that test would be Add_With3And4_7. I think it’s a simple and clear way of naming methods. Although, if you have a lot of parameters it will be a mess.

I also think that each test should be kept in a separate method.

 

 

First post

The first post of a blog is always the hardest to write. I have started a few blogs before, and the first one is always a pain in the neck. Usually I write about what this blog will cover, in great detail. But who cares? You will probably see my next couple of posts.

So this time a welcome and an introduction should be enough.

So, who am I?
My name is Daniel and I work as a developer for one of those new and hip company where everything is JavaScript *shrugs* and NoSQL. Before that I worked as a .Net developer which I still miss. I’ve been developing for at least 20 years and 10 of those years it’s been professionally. I’ve worked at a big consultant company, small start ups, medium size companies and huge companies. It’s been C, C++, C#, Java, JavaScript and much much more. And apart from this I of course code on my spare time as well.

That’s it about me….So welcome to ByteMeBlog.com!