Home / Archive by category "How we do"

Clean Code: Test data preparation or what test data builders are good for

Today I read this blog post about how to simplify test data preparation.

The author of the blog post states that setting up test data for tests is sometimes difficult and bloats up the test code, resulting in bad readability and maintainability. I completely agree with that.

The author continues by solving this problem by loading the test data from a file and using it in the test. That minimizes the code needed to set-up the test data, but results in a disconnect between the test and the data or example used for it. Leaving us with an obscure unit test.

We solve this problem differently.

Continue reading

Real World builds in .NET

How do you build your Visual Studio solution, verify your coding guidelines and execute tests?
What steps do you take when adding a new project to your Visual Studio solution?

Living in the past

Let me summarize my past experience. I have tried several different approaches, all of them involved build scripts, and Visual Studio Project Templates or manual editing of *.csproj files. I don’t like any of the approaches. Why? I will show you some drawbacks of this kind of build definitions.

Build scripts:

  • you have to learn a scripting language
  • you try to solve problems which you would solve in your preferred .NET language with less effort

Visual Studio Project Templates:

  • making up-to-date versions available to all team members is a PITA (pain in the ass butt)
  • update your templates and you still have to update all previously existing *.csproj files manually
  • if you change your build process (e.g. enable StyleCop) you have to release and distribute a new version of your templates

Manual editing:

  • enough said

Imagine the unimaginable

Continue reading

Ask a geek: mocking third party service in Selenium tests of an MVC application

We received the following Ask-a-geek question from Patrick:

I have the following scenario. MVC Application using Ninject and Moq for the unit tests.

We do some additional Tests using Selenium which testes JS etc. So the scenario we want to test is, that in a TestMethod we start IIS Express with the MVC project. Start selenium and do the clicks, check the results. That works all perfect.
Now we have a call to a third party webservice from our repository. In our unittests we used MOQ to mock that. In the Selenium test we want also to mock it. Currently we have this solution
– MVC web.config has a setting, in case that setting is available, we load inject a test repository containg the moq logic. So that means, when we start the test, MVC sees the new setting and instead of injecting the default repository we have the moq repository.

So far, all works good. But here the concerns
– not a nice solution, as all the moq is part for the productive solution
– Moq and testclass are seperated: the whole logic for the Moq is within the MVC solution (repositories) and not part of the Test-Project

Any ideas/suggestions/approches to have a nicer solution?

Continue reading

TeamCity: Improve Build Times with Compressed Artifacts

cross-post from http://blogs.jetbrains.com/teamcity/2013/06/04/improve-build-times-with-compressed-artifacts/

Do you work with build chains and artifact dependencies? Do you wonder why it takes so much more build time when your artifacts get bigger and bigger?

You probably have the same potential for improvement as I had in my current project. Read on to learn how you can get your builds faster and waste less time waiting for your builds to complete. A fast feedback loop is of major importance, especially in agile software development.

The issue

In the project I’m currently working on, we have a fairly complex build process with many artifact dependencies between the various stages in our build chain. At some time we felt the build started slowing down. In the next retrospective meeting my team decided that I should analyze the build process and implement improvements to get us back to fast build times.

In this post I’ll only write about how I implemented the improvements. Let’s have a look at our build chain first:


In the above diagram you see the 4 stages in our build chain: build, test, installer, publish. You can see that the artifacts of the Integration-build (.NET) are used in four dependent builds: 3 test runs and the installer. These artifacts are about 1.2 GB in size and consist of thousands of dll’s and other small files. Now, keep in mind that the TeamCity system has to copy those artifacts 5 times per build (e.g. 6 GB in small files). Why 5? – You got it. Once from the Integration-build (.NET) build agent to the TeamCity server (artifact publishing) and 4 times to distribute them to the 3 test run and the create installer agents (artifact resolving).

Remember what you learned about reading and writing very small files from and to a hard disk? It is very slow compared to writing one large file with the same total size. Let’s have some numbers to see the impact on our build times: Resolving the build artifacts takes about 20 minutes for each of the 4 builds. So, it takes 80 minutes of CPU time just to resolve the artifacts in our build, which is triggered on every commit. As we are running these 4 builds in parallel, we actually “only” lose 20 minutes with artifact resolving, but it’s still too much. And it causes a higher CPU consumption on our virtualized server environment.

How can we improve and get our build faster?
Continue reading

Legacy Code and Now What?

cross-post from http://blog.bbv.ch/2013/06/10/legacy-code-and-now-what/



Every day is a ground hog day. It is eight o’clock in the morning. You come into the office, look at the Scrum board of your current project and pick the next task of the user story with the highest priority. You sit fully motivated in front of your computer, open up your favorite IDE and start to implement the task. But wait! Something is wrong! First, you have to fully grasp the code you tend to put the feature into. But there is a lot of code in that area, which needs to be understood, analyzed and put into context with the feature you are implementing. You start drawing a sequence diagram of what is going on in that code but the more you dive into it the more confusing it gets. The motivation decreases, frustration chimes in. Maybe someone in your team can help you understand the code. You call your colleague, who immediately sits down with you trying to help understanding. Minutes later your friend has no clue either and tells you to “just freaking hack it into the code”. Despite feeling a bit dirty you have no other chance than to hack it. The feature has to be completed better yesterday than tomorrow! But you are a hero, aren’t you?! You can do it! The motivation comes back and finally you get the task done and the feature you are working on is ready to be demonstrated during the sprint review.

The sprint review starts, your product owner and your team members are gathered around the demo computer. You are first to show your new feature to the product owner. The feature works and fully impresses your product owner. Now, it’s your team mate’s turn to present the feature he has been working on. He starts presenting, but suddenly… BOOOM… the application crashes. Your colleague almost freaks out because he wanted to receive a pat on the back from the product owner, too. He blames you for killing his feature. The product owner gets angry and suddenly starts complaining about your team making more mistakes than pushing out new features. Your team mate finally says what your team always had in mind: He demands a rewrite of the whole software because you have reached a state where you cannot add any new features without severely damaging old ones. But guess what! Your product owner demands more features nonetheless. And he wants them now!

Do you recognize the situation? Let us analyze what happened here.

Continue reading

How we do the Daily Scrum in my team

In a typical Daily Scrum, every team answers the three questions about what was done, what is next and which impediments there are.

We moved away from this form of Daily Scrum because it is not very efficient and not focused on Sprint Backlog items. It’s not efficient because we do a lot of pair programming and several team members work on the same User Story at once. Therefore, some team members could only say “I did the same as already said”. This way of doing the Daily Scrum makes it hard to plan the next 24 hours as a team, too. Planning the next day is a team task and cannot be answered by a single team member for him- or herself.

So, what do we do then?

Continue reading