New and improved Test First Development using Eclipse screen cam!

Based on feedback from Ed and Erich, I decided to rerecord my screen cam demonstration. In the process, I’ve also changed the title. You can find Test First Develoment using Eclipse on the Evangelism site. This is a recording of a demonstration that I’ve been doing a lot lately; especially at Java Users Groups.

There are several points to this demontration. The most important point is that a tests first/top-down approach to software development does work (for more information, consider reading “Test-Driven Development” by Kent Beck). Especially in Eclipse which provides you with great power to make it work (get used to hitting ctrl-space and ctrl-1).

I’ve tried to improve the production quality of the demonstration by throwing in some fancy section introductions and cheesy fade and wipe effects (it sort of reminds me of the early days of Hypercard and all the unfortunate user interface designs put forth by stack designers). I did try to keep the silliness to a minimum and did stick to a consistent set of annoying effects. I also added my soothing voice to the demonstration which should more than make up for the cheesy effects.

Erich pointed out that I don’t use code completion totally consistently in the demonstration. For one thing, I never use it to provide modifiers for my methods and fields (though I do often use quick fix for this purpose). I have many excuses for this: I’ll have to decide which one I’m going to use…

This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to New and improved Test First Development using Eclipse screen cam!

  1. Ed Burnette says:

    This is much better than the first one. Here are a few suggestions for next time:- Start talking right at the beginning of the screencast. I thought my audio was off at first. I think it’s better if you’re talking the whole time but that may be a matter of opinion.- Lose the transition screens or at least go with something faster.- Slow down a little to allow the users to follow what you’re doing. For example when you create the first class it went by too fast.- Try to maintain a consistent volume level. You started to fade out at the end.- Keep the presentations focused and concise. There were some extra things in here that didn’t need to be there, like renaming the function parameters.- As far as TDD goes I think it might be better to write one test at a time. Also you didn’t need to save it; the editor was already showing you the errors when you were writing the test.

  2. Wayne says:

    Thanks for your feedback Ed. While I might agree with all of your comments in certain contexts, I disagree with your assertion that renaming function parameters was unnecessary. IMHO, the default parameter names were wrong and needed to be changed.Also, I disagree that its better to write one test at a time. I tend to write a few tests, but then focus on making them work one at a time. This probably more a matter of personal taste than anything (sometimes I do make them one at time, but normally they come in small groups). I certainly don’t write *all* my tests first.Again, thanks for the comments. Like everything else, the results will get more streamlined as I get more experience making these things…

  3. Ed Burnette says:

    Yes, the parameters needed to be changed but it wasn’t central to the demo. Anything you can leave out while still getting your central points across is a candidate for the cutting room floor, IMHO.I’ve been thinking about my comment about some things going too fast. Upon reflection, I may have changed my mind about that. After all, the user can pause and rewind, unlike a live demo. A good screencast is lively, packed with content, and moves along at a good clip. Some good examples are the famous Ruby on Rails one that launched RoR into the developer consciousness, and Strobl’s ones on NetBeans.Keep up the good work!

  4. Eugene Kuleshov says:

    Original demo by Carlos E. Perez went little further (though wer bit more chaotic). I think it is a good idea to show how to stop in the AssertionError exception in the debugger and fix code right while running under debugger. The point is to never restart test at all. Those who developing web and j2ee apps will appreciate that very much.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s