Testing a periodic worker

I came across somebody that was asking about how to test their code. They had a function that would do certain work at short intervals and then some other work after a longer period of time. They provided a simplified version of the code and it looked something like this. They had coverage for the short period work (I guess functions foo and/or bar in the simplified example had some side effect they could test for.

What is the purpose of a test name?

Since I'm certainly a person who has been passionate about how tests are named, this article first made me a little upset since it almost suggested Test123 to be a good name. But as I kept reading I started to question my own crusade regarding test names quite a bit.

Slow tests, courage and zombie driven development

When I was going over my old posts from January 2009 I had a flashback of how I for a while aimed at posting something every other day. Today I must say quality may have suffered from that and I apologize... So here are the highlights...

Go for C# developers: Where to define interfaces

When writing Go code the general guideline is not to create interfaces unless it is really needed. A good example would be an interface with only one concrete implementation. Now for the mind boggling part; in C# we would probably create that interface if the type needs to be faked in some test while in Go you wouldn't. Or actually you would. But in a different place...

Another example on ways to to make your code testable

Before you go crazy on me screaming that making code testable for the sake of testability is bad I'd like to agree. However testable code have other nice properties like loose coupling for example - something you likely want. Anyway, in this article there is a great comparison between using inheritance vs composition to implement a class and how that affects both the design of the class and the tests. TL/DR; use composition and dependency injection. Please.

The 2008 advent calendar - 24 ways to write a test

Oh yes I love December 2008. I decided to challenge myself and write the same test in 24 different ways. And it was an interesting experience!

Go for C# developers: Unit testing

Let’s talk about unit testing and Go. The fact that unit tests typically are placed side by side with the code (in the same package as the code under test) and how Go deals with exposing functions outside of a package leads to some interesting things.

Peek inside Netflix A/B testing

Just a quick suggestion for today. Read this article on A/B testing at Netflix as it both shows you the importance of supporting A/B testing in your platform as well as an interesting insight into how we humans work when looking for something to watch & chill.

What does a good exception message look like?

Today I have to bring up a great article that is over a year old. They topic is what exception messages really should look like. As bonus I would like to increase the scope of the discussion to also include log messages and test failures.

Don't hold me accountable for old opinions

Once in a while I get a comment about something I wrote a long time ago and sometimes that is embarrassing as the opinion I expressed a while back might not be how I feel today on that subject. Hence I decided to look into some old blog posts and see how bad it is...

Yet Another Code Coverage Rant

Instead of me ranting over why code coverage measurements can be good but in general are used in the wrong way; why don't I let somebody else do it for me...

Web service scale testing

When I say web service scale testing I mean testing to figure out how many instances of your service you need. This type of testing is really easy to explain but typically hard to get right.

Monitoring is Testing

So a while back I was approached by DZone for some feedback on software quality. After ranting for an hour I was asked if I would mind writing an article on the topic. So I did and it got published earlier this week.

Timetravel in C# done right

Testing things where you need to fake time is not hard given the right abstractions. That is why when I read this article I felt really sad. Because while the article describes one way to fake time it does so by breaking three fundamentals which is pretty hard in three lines of relevant code...

The I have no idea what I'm testing anti-pattern.

It is no secret that I'm not a big fan of service locators in general, but even if you are a fan of those there is a pattern I really don't want to see in unit tests. I will call this the I-have-no-idea-what-I-am-testing-anti-pattern.

Faking 3rd party dependencies

When it comes to dealing with third party dependencies in my code I've used the same trick for a long time. But I was recently introduced to a new trick that I have mixed feelings about.

Testing with fakes or stubs? That is the question!

I like testing with stubs. But once in a while I encounter people that rather use fakes. And that is a pattern I try to avoid.

Spies and Stubs

I was reading this article which is a response to an email from a person liking mocks but disliking spies. Before starting to read I was confused since I personally dislike mocks and spies sounded even worse. However it turned out I was wrong.

What is your test ROI

When we write code we sometimes get carried away and forget to think about if we are spending our time right. However more common I see people (including myself) forgetting to think of cost vs benefit of the tests we write.

Writing async tests

Ever since async/await was introduced in .net 4.5 I've seen people happily using those keywords in their (unit) tests. A usage I believe to be a mistake.