Several comments this week contribute to this week’s post.

The first, and the one that pushed me to write this post, is a discussion over at Simple Programmer on a post called “Cracking the Coding Interview” where I made the following statement,

Read More

For the purposes of this post, I’m going to assume that you already have the NUnit Test Runner installed.  The question you are looking to get answered is, “How do I run NUnit from Visual Studio” or even more importantly, “How do I DEBUG NUnit test from Visual Studio”.  The following step by step should help you.

Right click on the project in Solution Explorer that represents your test project.

From the resulting menu, select “Properties.” In the resulting window, select the “Debug” tab from the left-hand side of the window.

You will want to select “Start external program” and point it to the UNnit runner that got installed when you installed NUnit.

Now, whenever you run this project, with or without the debugger, NUnit will start up.

Note: there is no reason to pass parameters telling it what DLL you want to run because it will load the last DLL it had up.

But, if you wanted to do that, you could pass the location of the DLL as a parameter to the GUI runner.

There are other parameters you can use.

Read More

When I was in college, there were some guys I hung out with who played this game called “Questions” which they got from some book.  Actually, it was a play. Anyhow, the basic rules are:

• You can’t answer a question with a statement
• You can’t hesitate or make a false start
• You can’t repeat a question that has already been used
• You can’t ask a rhetorical question
• You can’t ask an unrelated question.

There was also this podcast at DotNetRocks where they were talking about a beer app and how they had added game elements to the app by adding badges for various types of beer to get you out of your comfort zone.  Maybe there is one for “My first beer that I liked” because I’ve yet to find something I like.  But give me a good Merlot! All of this got me to thinking about how we might turn Test Driven Development into something of a game. There are several people who have already addressed the Gamification of TDD

Read More

As you advance in your career, you will inevitably want to improve as a programmer.  And as you search the Internet and read various web post on the subject you will also inevitably end up with a bunch of task you should perform that will make you better. For example, if you’ve been following this blog lately, you’ll notice that I’m a big proponent of Test Driven Development.  You would naturally expect me to state that to be a better programmer, you should practice Test Driven Development. There has also been a lot of emphasis recently on good basic programming principles like DRY and SOLID. The list could go on.  Here are a few you may be interested in experimenting with:

• Code Reviews
• Paired Programming
• Learn and Implement Design Patterns
• Reduce Method/Class Complexity
• Practice Code Katas
• Participate in the Community
  • Start a Blog
  • Participate on StackOverflow
  • Read and  Comment on other people’s Blogs

And while all of these and more are good ideas, none of these ideas will actually MAKE you a better programmer.  Why?  Because becoming a better programmer is mostly about becoming a better person.

Read More

At the risk of making half of my audience think I’ve gone off the deep end, I’m going to address a topic that I’ve only recently REALLY begun to understand, in part thanks to Soft Skills.

When I’ve heard the topic of “Limiting Beliefs” come up, it has almost always been in the context of something along the lines of “What the mind can conceive and believe, it can achieve.”  Which is easy to disprove.  At least it is out of context!  I mean really, if I can conceive and believe myself to be a butterfly, it just isn’t going to happen! However, the opposite is pretty easy to both accept and believe.  And that’s what I want to talk about today.  But even then, it probably isn’t what you are expecting.

Read More

Several weeks ago now, I started learning Node.js.  Why?  Well, for a couple of reasons.  First, all the cool kids are using Node.js.  Second, I wanted to use Istanbul to get an idea of how well my javascript code is covered by test and that runs under Node.js.  Third, Node.js is going to show up in the next version of Visual Studio.  And finally, I just like to learn new stuff.

Read More

In response to my post “Excuses For Not Testing” Kris K asked:

There is also another side of Unit Tests. Some companies are so fixated they aspire to have 100% Unit Tests coverage and they make programmers write Unit Tests for legacy code for no reason. Just for the sake of having Unit Tests. … [I] wonder if you had any similar experiences and what you think about this approach. I guess the 100% extreme is better than no tests at all, but it can make the developers very bored and feeling useless.

And my initial reaction to this was, “WOW!  So much to respond to here.  I think this is worth a blog post.

Read More

This past week I’ve been thinking a lot about changing habits and how much of our lives habits influence. To be clear, I would define a habit as something we have learned to do as an automated response to some trigger.  Something we no longer think about doing, but we just do because … well … because we’ve always done it that way.

I have some bad habits:

• Eat something sweet when I’m tired or bored.
• How I react to particular situations
• … others I’m not so willing to share publicly …  :)

And some good habits:

• Wake up before 4:40am
• Go to bed at 9:00pm
• Write a blog post once a week
• Watch PluralSight videos for 30 minutes every day.

And some habits I’m trying to form:

• Exercise every day
• Take my vitamins
• Work on my book for 30 minutes each day

Read More

As you start your journey down the road of Unit Testing you will discover that part of what makes code testable is this concept of Dependency Injection.  As you explore further, you will see people mentioning various Dependency Injection frameworks.

You may naturally assume that to implement Dependency Injection, you will need to select an use a Dependency Injection framework.

But, Dependency Injection has nothing to do with using a Dependency Injection framework.  The frameworks are there because:

1.  much of our existing code is code that has too many dependencies and the framework helps us break those dependencies without having to refactor too much of our code and
2. to give us a way to easily swap out one object for another when our code is structured in such a way as to not have dependencies at all.

Read More

Last week we looked at a few excuses developers give for not testing their code as they develop it (Excuses For Not Testing).  We finished that by mentioning that most of the code you write simply isn’t testable.  You can’t practice Test Driven Development on something that isn’t testable in the first place. And there, folks, is why Johnny can’t test.

Read More