March 2012 Archives

Class Blog #1 - Testing, testing, 1-2-3

| No Comments

Hi. I'm a computer science student at the U of M. And a few other things.

So, we've got this class - It's called program design and development. 3081w. The w stands for writing, and it means we have to write for this course. Shockingly enough, that's why we're writing this blog.

We've been tasked with writing a blog about our first project in the course, which was a pair project in programming language parsing. This project was to write a piece of code that would 'tokenize' the input, which was code in that language. This means to recognize keywords and other variables in the overall text of the program and to annotate what they are and keep track of them in a list.

A little confession about my partner and I: We've worked extensively together. This is our fourth class in which we've worked together closely, and we're also doing development projects together outside of school.

Still, we've never done code like this before. Writing proper test cases forced us to think differently, and gave us a better split on the work. Writing testable code means writing code in smaller chunks, which made it easier to work in parallel.

In fact, the testing was the most interesting part, to me. I did most of the testing, and my partner did most of the implementation. Writing the tests was a fascinating way to elucidate what the program had to do - Like writing the most detailed specification imaginable. Pass the tests, and (if they were well written) you've achieved what you set out to do. And not just that, but you KNOW you've done it.

Writing the tests forced me to think very carefully about each and every aspect of the code that would be implemented, but it forced me to think about it from the "what does it need to do?" perspective rather than the "how do I do it?" perspective.

Our decision to split up the work like I described - I wrote most of the tests, my partner did most of the implementation - worked very well. It allowed us to work mostly independently, but on the same project. We put our heads together and did a bit of design, then I wrote the first tests, then my partner started implementing while I wrote more tests.

When he'd finish a piece of the implementation, I would run tests against it. We'd find problems in the tests and in the implementations, but we'd catch them right away. When the time came to put our pieces of code together in to the larger program and run it, it came together smoothly. We worked together to iron out the few problems with the tests and implementation, but on the whole, it came together almost perfectly.

This was a nice change from many previous projects, where if it comes together cleanly... Well, it's a surprise, at the very least. The testing clearly and dramatically improved the quality and overall robustness of our end product.

It's hard to say what didn't work well - Overall, once we got started, the project was a pleasure. The specifications were a bit scattered - split between several web pages and in file documentation - but once we dug in, it became clear what needed to be done.

One note is that by the time we got to thinking about the Eve of Destruction tests, we were burnt out and decided to work on our other homework instead.

Overall, our process went well. It was a very nice experience to be able to work on the same problem in parallel, which the test cases and the segmentation they imposed allowed us to do.

Other than getting started earlier - we started the Tuesday evening before the project was due - I don't think there's anything I'd change about our process. It's possible for the next iteration we may do more of our work remotely, instead of getting together to work.

Oddly, I'm excited for iteration 2.

Blog!

| No Comments

Blog!

About this Archive

This page is an archive of entries from March 2012 listed from newest to oldest.

Find recent content on the main index or look in the archives to find all content.