Speaking about Unit Testing Javascript on Thursday at CONDG!

Posted on February 21st, 2009 in Uncategorized by Jon Kruger

I’ll be speaking at the Central Ohio .NET Developers Group this Thursday, Feb. 26 at 6pm… I’ll be talking about Unit Testing JavaScript using Test Driven Development.  We’ll go through what TDD is and how it can help you and show you how to write JavaScript tests against a sample application using QUnit.  Hope to see you there! (Oh, and there’s free pizza too!)

CONDG meets at the Microsoft building at Polaris… the address is 8800 Lyra Dr., Columbus, OH 43240.


Kick It on DotNetKicks.com

Your personal TDD accountability partner!

Posted on February 15th, 2009 in TDD, unit testing by Jon Kruger

The next time you are getting lazy about not writing your tests first and you need someone to keep you in line, you have someone that you can turn to!


Kick It on DotNetKicks.com

Running QUnit tests using continuous integration

Posted on February 11th, 2009 in JavaScript, unit testing by Jon Kruger

On my current project we will be using QUnit to writing tests for our JavaScript.  What would be really nice is if our CI build could run JavaScript unit tests.

Well, it can!  It only takes a few magic potions and sacrificing a few small animals.

Luckily someone had done this before and blogged about it so I pretty much just had to follow instructions.  Here’s the long and short of it:

  • We had to get WatiN, which will be used to create an instance of Internet Explorer that will run our HTML page with the QUnit tests in it.
  • We had to get the IterativeTest addin for NUnit.  This will create one NUnit test for each QUnit test.

In the code, I added an IterativeTest (a test decorated with the [IterativeTest] attribute) that will run all of the QUnit tests.  Since we all use ReSharper and ReSharper doesn’t recognize the [IterativeTest] attribute, I also added a normal NUnit [Test] that will run all of the QUnit tests inside one test and fail if any of the QUnit tests fail.  So we should have all of our bases covered.


Kick It on DotNetKicks.com

Tips for becoming a faster developer

Posted on February 1st, 2009 in Uncategorized by Jon Kruger

One of the common complaints that I’ve been hearing about our industry is that our industry lacks quality in general.  The evidence of this is this never ending cycle of rewriting software over and over because it is unmaintainable, buggy, etc.  Many people would say that this is sometimes a result of developers throwing code together quickly without taking the time to think out their design, write unit tests, or manually test their code. 

Thankfully the pendulum seems to be swinging and people are starting to expect higher quality from themselves and from the people that they work with.  More and more people are jumping on the TDD bandwagon (at least the people I work with are). 

However, speed is still very important –- that is, the amount of time that it takes a developer to complete a task or the amount of time that it takes for a team to complete a project.  The fact of the matter is that we all have deadlines for our projects (well, maybe not if you’re working on open source projects).  Hopefully those deadlines are realistic, but they are deadlines that we have to meet.  So quality is definitely important, but speed cannot be ignored.

It seems to me that there is a stigma against developers who say that they work fast.  It seems that if you walk into an interview for a developer position and you say something like, “I’m capable of getting a lot of work done in a short amount of time,” you might as well keep looking because the interviewer will often times assume that you write crappy code and don’t care about quality.

But what if you are able to work quickly and not compromise on quality?  That would be the best of both worlds!  Just like we should all strive to write better quality software, we should also strive to get it done in as quickly as possible (without compromising on quality, of course).  Here are some ways that you can do this:

Become a keyboard ninja

They put those keyboard shortcuts in Visual Studio for a reason, you know.  If you’re writing .NET code you’re probably spending most of your day using Visual Studio (or another IDE if you’re using another language).  So why wouldn’t you take time to learn the keyboard shortcuts?  If you are using ReSharper (and you all should be), there are even more keyboard shortcuts to help you.

When I got my first job, I worked some guys whose goal was to never use the mouse.  These guys knew the keyboard shortcuts for everything, and they sure could get around fast.  Watch somebody who uses the mouse a lot, and watch how long it takes to stop typing, grab the mouse, drag and click, and go back to the keyboard.  It totally takes you out of your rhythm.

If you want to learn to use the mouse less, it really isn’t that hard.  Go print out the keyboard shortcuts for Visual Studio or ReSharper and tape them up at your desk.  Then anytime you reach for the mouse to do something in a menu or a toolbar, look on your cheat sheet and find the keyboard shortcut.  Highlight it on your sheet so that it’s easy to find next time.  You’ll be a keyboard ninja in no time.

Create easy-to-use frameworks

I’ve been on projects where it was really difficult to do simple tasks because the application’s framework put so much burden on the developer because it was way too over-complicated.  Sometimes things have to be complicated, but many times they don’t have to be.  When I’m designing frameworks, I will spend more time on writing framework code if it will make life easier for the developer using it.  Frameworks should help developers get things done, not hinder them.  The success of your project may hinge on this.

Use code generation tools

If you find that you’re doing a repetitive task over and over again, take the time to set up some code generation templates to help you generate that code.  There are many ways to do this:

Don’t get stuck writing plumbing code over and over again.  Usually there is some repeatable pattern that you can recreate using a some kind of code generation tools.  Every developer should be at least somewhat familiar with these kinds of things.

Control distractions

There are lots of things that can distract you while you’re writing code, like meetings, emails, IM, Twitter, etc.  Sometimes you can’t always control these (e.g. meetings) but the rest are under your control.  The world is not going to end if you can’t check your email, send IMs, follow Twitter, etc. for a day.  I’m not saying that you should always shut those off.  I’m just saying that we all need to be careful that they don’t become a distraction.  It’s really easy to get caught up in discussions on Twitter, but remember, you’re being paid to produce, not discuss things on Twitter.  (If you are getting paid to participate in discussions on Twitter, then lucky you!)

Buy ReSharper

I think I’ve already mentioned ReSharper several times now.  It’s only $199 for a personal license.  I don’t know how I wrote code for so long without it.  My company bought a license for everyone on my team and it was the best money they ever spent.  Some of the refactoring tools and keyboard shortcuts are really useful if you’re doing TDD and creating a lot of interfaces.


Kick It on DotNetKicks.com