I'd like feedback on the following curriculum. I'd especially like to know what you guys think of taking a "test first" approach to teaching a language like ruby. TDD on Week 3. Too early? Students should have some prior knowledge in programming, but not necessarily OO, testing, or dynamic languages. You think it is too much?
Personally, I think it'll be a medium sized hurdle that should allow the rest of the quarter to go by a bit smoother. All homework will be test driven, allowing the students to know ahead of time that they're right or wrong.
What do you think?
Start date: Oct 2007 End date: Dec 2007
I... can't... learn... that... slow...ly... :P
Yes, totally agree! We teach all our apprentices to do test first. See: http://www.ywesee.com/pmwiki.php/Ywesee/Team#Lernziele_Praktikanten
A test driven approach works very well in my opinion, as long as you lay the ground work down properly. It seems like a fine outline to me, even though I don't see any mention of debugging.
YES! I've been trying to convince people that one of the main problems with how we introduce people to programming and new languages is that we don't introduce them to testing at the same time. People need to see, early on, just how important and valuable testing is and how much better it will make your life.
You may want to touch on connecting to and querying SQL databases (just the basics) since that's such a common task.
This idea sounds great!
Are you going to be teaching an online version of this course??? If so, sign me up!
Oh god yes! Please teach them testing up-front! I can't tell you how many well-credentialed people I've had to send to remedial test-school just to get them productive. Getting people to understand that testing isn't after-the-fact and it isn't all done up front, but rather an organic part of the process is crucial. Kudos to you for emphasizing this.
Why wait till week 3? Are you planning to do any live coding to demonstrate the concepts of week 2? Can you do that in the form of writing tests? This will get your students some organic exposure to the concept before you get religious in week 3 and point out to them you've been doing TDD all along without formalizing it.
Better yet, why not make TDD a concept orthogonal to the course material and just do it? Don't talk about it, just lead by example. That'll give you one more week to talk about Ruby stuff. Then, at the end of the course, mention in passing that oh, by the way, have you heard of TDD? Well, we've been doing it all semester. Have a good break!
I've been teaching high school computer science for a few years and just completed a first year in Ruby.
I think that TDD is the best way to teach it. Without knowing more about your students, setting, and expectations (though I'd guess first or second programming class at a university) it is difficult to give meaningful criticism.
The thing that does stand out to me is the question "How soon can they DO something?" The first week you have a lot of background material that isn't actually essential for writing a program. Distribute good instructions about the installation process before the semester begins. Bring CDs with applicable installers to your first class. Sure only 20% of them will have it setup ahead of time, but those who don't say "Oh $&@, this class is intense." Have them writing programs the first day.
That's one thing that I came to really appreciate about teaching Ruby - I didn't have to frontload everything. I didn't spend 30 minutes explaining strings at the beginning - we just wrote "Hello, World." Get them writing things ASAP! Do some stupid user input with gets.chomp. Write a loop that can sing "99 bottles of beer on the wall." Just get their attention that the class is about creating things - not just learning a bunch of crap.
I would really like to work on a remote testing platform. It would be awesome if you could have a "server" that hosts tests and tracks statistics. Users have some kind of client that takes their code, connects to the server, runs the tests, and spits out the results. In a classroom setting maybe you project a stat board that displays student names/aliases and which tests they've passed. You could have the server using the testing metrics to assign the numeric grades for each student. Get a rough idea what I'm talking about?
I'd always love to talk about teaching Ruby and/or CS and can be reached by email at "jeff" at the domain linked above.
Ryan,
I've introduced TDD in an introductory CS class before, with good success; I think it was the third programming course they'd taken. I asked students to build a tree data structure in Java and supplied them with tests. It simplified things for them (most wrote just enough to make the tests pass - joy!).
To my pleasure (and after only minimal prodding), some even figured out how to use Ant and Clover and gave me scripts that generated test reports, including coverage reports.
Maybe providing them with the tests for the first assignment, before asking them to write their own would gave them the guidance they need to know what to do?
Please let us (or just me!) know how it goes!
Ryan, depending on the background and quality of your students week 3 could be either too soon or late. I have noticed that students (as perhaps users of computers in general) tend to quickly settle on routines to accomplish a given task. So one problem with introducing testing late (as in after the first assignment) is that students will not change how they do things. As a result they write the tests after the do the work but before they turn it in.