Stacey asked me for a refresher on Test Driven Learning for so here we go.

Test Driven Learning is a software engineer's articulation of Wiggin & McTighe's and Pedagogy" course at Purdue.

Many software engineers are familiar with the process of Test Driven Development (TDD).

  1. Decide on the goal.
  2. Write the test ("how will you know if it's working, exactly?")
  3. Make the code pass the test.
  4. Celebrate.

 

Test Driven Learning (TDL) simply says "it's the same thing... for your brainnnnn!"

  1. Decide on the goal ("learning objective").
  2. Design the assessment ("how will you know if you've learned it, exactly?")
  3. Go through the experiences/etc. you need to pass your assessment.
  4. Celebrate.

 

That's it. Really.

Step 2 is the part most people flub. With software tests, you have a compiler/interpreter forcing you to be precise. With learning assessments, you don't -- but you need exactly the same level of precision and external execution. If you asked a group of external people (with appropriate expertise) whether you'd passed the assessment you set for yourself, there should be no disagreement. If there's disagreement, your assessment needs a redesign.

A good assessment is a goal that helps you stretch and reach it; sometimes it encourages you to do more. But sometimes it also gives you permission to stop doing stuff -- you've written the code, you've delivered the talk, they met the criteria you set --  and now you're done. You can absolutely set a new goal up and keep on learning. However, you're no longer allowed to say you Haven't Learned X, because you've just proven that you have.

Here are some rough-draft quality TDL assessments you might start with, and a bit of how you might improve them.

I will learn Python. (What does that even mean? How will you know you've learned it?) I will complete and pass any 50 CodingBat exercises in Python. (But I could do that by solving 50 really easy problems.) Only 10 of those 50 problems can be warm-ups, and at least 20 of them must be Medium difficulty or greater. (Does it matter if you get help with the problems?) Nope, I can get as much help as I want from anyone, as long as I could explain the final solution to another programmer.

I will get better at testing. (What do you mean by "testing"?) I write a lot of code, but I've never written tests for any of it. I hear the nose framework is nice. (What do you mean by "better"?) Well, I've never written a test at all, so even going from 0 to 1 would be an improvement. I could use nose to write tests for 3 different pieces of working code I've already written. (Do these need to be big or exhaustive tests?) Nope, I'm just trying to learn what writing tests is like, not get full test coverage on my code... at least not yet. Even if I write a 3-line test that checks out one minor function, it counts as one of the 3 tests. (What does it mean for a test to be "done"?) When someone else can check out and successfully run my code and my test suite on their computer without needing to modify either bit of code, it's done.

I will understand how databases work. (By "understand," do you mean the mathematical theory behind their design? Or how to actually implement and use one?) Oh geez, the latter. I don't care about the math so long as I know how to interface with a database. Any sort of database. (So you need to make a demo.) Yeah, but that's not enough; I can blindly type in code from a tutorial, but that doesn't mean I'd be able to field questions on it. (What could you do about that?) I will give a presentation to fellow Hacker Schoolers demonstrating a small database interaction in code I have written. That's an easy binary to check; either I've given the presentation or I haven't.

Thoughts, questions, ideas? Got your own example TDL assessment (at any stage of revision), or ways to improve the ones above? Holler in the comments.