Save Time with Test / Source Toggling Macro

For the past 2-3 years all the development I have been doing has been test driven. I don’t really want to count how many hours I have spent looking for corresponding test file / source file.

Last week I remembered that I use to have the same problem doing c++ development only then it was the cpp file / h file. To solve this tedious problem a friend of mine gave me a visual studio macro to toggle cpp and h file. I figured the same should be possible for test and source file.

Most of the projects I work on still use the convention of one test suite per class. For example the Person class would be tested in the PersonTests suite. If you follow a similar pattern you can use this macro for toggling between source file and test file.

Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports System.Diagnostics
Imports System.Windows

Public Module TestHelpers
    Const CODE_FILE_SUFFIX As String = ".cs"
    Const TEST_FILE_SUFFIX As String = "Tests.cs"

    Public Sub SwitchBetweenSourceAndTest()
        Dim currentDocument As String = ActiveDocument.Name
        Dim targetDocument As String = String.Empty

        If currentDocument.EndsWith(TEST_FILE_SUFFIX, _
        StringComparison.InvariantCultureIgnoreCase) Then
            targetDocument = SwapSuffix(currentDocument, TEST_FILE_SUFFIX, CODE_FILE_SUFFIX)
        ElseIf currentDocument.EndsWith(CODE_FILE_SUFFIX, _
        StringComparison.InvariantCultureIgnoreCase) Then
            targetDocument = SwapSuffix(currentDocument, CODE_FILE_SUFFIX, TEST_FILE_SUFFIX)
        End If

    End Sub

    Private Sub OpenDocument(ByRef documentName As String)
        Dim item As EnvDTE.ProjectItem = DTE.Solution.FindProjectItem(documentName)

        If Not item Is Nothing Then
            Forms.MessageBox.Show(String.Format("Could not find file {0}.", documentName), _
            "File not found.")
        End If
    End Sub

    Private Function SwapSuffix(ByRef file As String, ByRef fromEnd As String, _
    ByRef toEnd As String) As String
        Return Left(file, Len(file) - Len(fromEnd)) & toEnd
    End Function
End Module

I have mine mapped to alt-O.

If you haven’t used Visual Studio macros before you will get a annoying balloon every time you trigger the macro. Check out “How to disable Visual Studio macro “tip” balloon?” on Stack Overflow to solve this.

Estimating in Trees, Probing the Unknown

One of the biggest problems for me ever since i started doing professional software development has been estimation.

Back in the dark ages we used to get a huge spec and spend a couple of weeks going through it estimating every feature in hours. We did this because the business people SAID they wanted to know the hours.

This obviously didn’t work since we always got it wrong. When I started thinking agile I learnt the trick of relative estimates; this revolutionized everything. The problem was that while we changed, the business stayed the same. In order for us to tell someone how long something would take we still needed a initial backlog. Usually it takes some time to spec a system, even in stories and honestly doesn’t this feel a lot like big spec upfront revamped?

I figured that there has to be a better way to solve this, all we really want is a rough estimate between here and there nothing to detailed. A educated guess.

At Öredev 2007 someone (can’t remember who) told be about estimating in trees. This is basically the idea of relative estimates applied iteratively over and over again. When estimating in trees we work with different levels of granularity and drill down at certain spots to probe how big something might be.

What we try do is split the problem into smaller and smaller chunks and weigh them relative to each other until we find us at a comfortable level of granularity.

Let’s demonstrate. Assume we are building the application, call it “Star Monkey DB”, our first level might be the application itself.

For the next level I like to use epics, but you could also use wireframes or use cases. Anything that is smaller than the previous level.

Now we estimate! Of course we do this using relative estimates and preferably with the whole team present. Pick a reference item (here Epic 3) set it to two epic points and estimate the rest in relation to that epic using your favorite estimating technique.

Now take your reference item and break it down to stories.

Estimate again! Pick a reference story, set it to two story points and estimate all the other stories relative that one.

Now we know that 2 epic points are 20 story points; this means that the Star Monkey DB would take, roughly, 170 story points to build. If your team has a established velocity your done. If not you’ll have to do a estimated velocity to find out how many iterations you think you need.

This works well when estimating something that does not have a complete backlog. The results can be used to discus cost and time frame of a project without doing the much dreaded “pre-study phase”.

This technique has worked well for me and given surprisingly good results. Keep in mind though, this is a rough estimate and you might want to do some sort of worst case/best case before handing the results over to any business people.

It’s Not the Face, It’s the Brain

Finally we have a new layout.

I spent about a week messing about with the layout of this blog. It was a really painstaking flashback of PHP, HTML and CSS all mangled into each other and intertwined.

Last night I took everything I had built during the week and threw it away. I settled for this nice wordpress theme which someone else built. It’s not unique but it’s clean, simple and customizable. And it gets the job done.

The point is, when you are doing something custom that doesn’t add to your core domain, the part of your product which separates you from others, then don’t do it. Find something that is a decent fit and solves the problem, then move on to working on your core domain.

The face is not the core here; the brain is. There is really no point for me to spend days on the layout. Somebody else has already done that and maybe for them this is a part of their core domain.

PS. If you are wondering about the “Der is no Fluffy, only Zuul!” line, it’s a caption from a lolcat that is currently guarding our scrum board. I had to put something there to make the layout look nice so I went for the lolcat .DS

The Importance of Deadlines

Usually the word deadline sends a chill down everyone’s spine. Maybe this is because it contains the word dead or maybe we all just have bad memories from deadlines gone south.

However deadlines are essential to being productive both as a business and as an individual. The problem is that we usually set deadlines to far apart. Yes, we usually have too few deadlines.

When I was studying informatics the deadline was usually the day of the exam. This meant you didn’t actually have to learn anything until that day. Thus there was always a feeling that we had plenty of time to learn… …until there was only one or two days left. Almost everyone I knew studied like mad the last days before the exam to cram a 500 page text book into our heads.

Usually this worked to solve the problem, i.e. pass the exam, but the quality of the knowledge was really bad. The net result was that a few days later most of what we learnt, those last days right before the exam, was gone.

If we instead had many small exams spread out over time, more deadlines, we would have been forced to study at a sustainable pace giving our knowledge better quality.

Agile practices understand and embrace this. We have iteration “deadlines” every 1-4 weeks. We also use daily stand-ups and burn down tracking to set implicit deadlines within the team, each and every day!

This leads to a sustainable work pace and a higher quality of the end product. Think of that the next time you have a looming deadline. Maybe it isn’t the deadline that’s the problem maybe it’s that you had too few deadlines along the way.


Get every new post delivered to your Inbox.