fewer-but-better

git / jenkins and tests, huzzah

leave a comment »

Exciting stuff happening at work right now includes:

1. switching the team from SVN to GIT, which will significantly change our QA / Release process (yay!)

2. rolling out a Continuous Integration tool (yay #2) (we are going to go w/ jenkins)

3. talking about changing our development culture re: developer written tests.

#1 and #2, plans to roll out a CI tool and use GIT instead of SVN, have been in the works for the last 6 months or so.   We recently hired 2 new developers (both awesome) and one of them has used GIT (no one else on the team had).  I think that having at least one person on the team who has actually used the new system has given us more confidence in making the change. Well, that’s reasonable. After all, it’s not a unicorn. ; p

But what’s the use setting up continuous integration for your team if no one is writing tests?

We don’t currently have a process that encourages or requires devs to write unit or integration tests.  We don’t, in practice,  run developer written tests before we build or after we commit, etc..  Why would any developer be inspired to write tests if she knows they won’t be run?

I’m not a big believer in self discipline.  Not that I don’t think it’s a good thing, it’s simply not effective, sustainable or common.  Same thing goes for disciplining groups and processes.  Better to set up a few automated checks so we don’t rely on fallible humans to remember to ‘do-the-do’.

A CI tool will run some set of unit and integration tests according to different intervals or actions (IE, nightly, weekly, on commit, on build, etc.)  Deploying a platform that runs the tests regularly will provide a reason to write tests. (Utility!)  Requiring that tests be written means they probably will be.

But we also have to deliberately change our culture.  We have to define what we mean when we say “unit” test or “integration” test… Those definitions vary from shop to shop and sometimes from dev to dev.  We need to come up with a set of best practices and examples.  What’s the smartest way to test our app?  I think we should not *assume* that all developers know how to write (good) tests.  It is a different skill set, and if you are not practiced at doing it you might be quite at sea when you are all-of-a-sudden required to.  Rather than hope that someone would ask for help,  we need to set up a series of brownbag sessions where we go over test writing for different scenarios (batch jobs / controller tests / unit tests / network or 3rd party / mocking).

Talking through some of these test writing scenarios with a few guys on the team has made me see how writing test-able code might change the way we write some of our code (business logic in the controller anyone?).  Our app is a  Java / Spring MVC app – while I understand the MVC pattern in theory, I’ve never actually built one myself.  In order to be better informed in some of these conversations, I’m going to make an app using Ruby on Rails. Why Rails? Well, honestly it just looks fun.  I used Python and Pyunit at my last job for QA stuff and I’ve messed around with Django enough to have gotten a taste for the basic flavor there.  But I’ve never written any ruby, so that’s interesting. Why not write a Java MVC app? Um, do you really have to ask?

About these ads

Written by fewerbb

April 23, 2011 at 2:12 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: