<br><br><div class="gmail_quote">On Wed, Mar 23, 2011 at 12:11 PM, Laura Creighton <span dir="ltr"><<a href="mailto:lac@openend.se">lac@openend.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">In a message of Wed, 23 Mar 2011 08:37:24 MST, "C. Titus Brown" writes:<br>
>It may be that we get our students off to a bad start somehow, but my<br>
>experience with our 2nd and 3rd year students is that they are so<br>
>immature as programmers that they often don't get what to test for,<br>
>they have no idea what a "specification" is, and, as a result, their<br>
>tests are not clear expressions of anything.<br>
><br>
>Or, to put it another way, learning how to test is just as hard as learni<br>
>ng<br>
>how to program. Since we don't know how to teach the latter, it's not<br>
>clear to me why we would know how to teach the former :)<br>
<br>
</div><snip><br>
<br>
I think that learning how to test is a lot more ammenable to rote learning<br>
than programming in general. I think that if your students worked their way<br>
through the unitesting chapter in<br>
<a href="http://diveintopython.org/unit_testing/index.html" target="_blank">http://diveintopython.org/unit_testing/index.html</a> they'd end up with a<br>
better idea of what a test should be, just through training. And<br>
making more training exercises isn't that hard. Start with ones<br>
where the specifications are already given, and work your way into<br>
making the students come up with their own specifications. One<br>
fun way we do this here (but these are children, remember) is to<br>
divide up in teams, and then make specifications, and then make<br>
tests. Then develop the code. And then finally -- make the other<br>
groups run your tests! The people with the most complete specifications<br>
get to watch the others code fail the test. Great fun around here.<br>
<br>
I also suspect that some of those tests that weren't a clear expression<br>
of anything were attempts by your students to capture their own thinking<br>
about how to implement something. This, too, gets better with practice,<br>
if only because you learn to stop showing your instructors the 'weird<br>
idea but not really a test' things.<br>
<font color="#888888"><br>
Laura<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
testing-in-python mailing list<br>
<a href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a><br>
<a href="http://lists.idyll.org/listinfo/testing-in-python" target="_blank">http://lists.idyll.org/listinfo/testing-in-python</a><br>
</div></div></blockquote></div><br>I don't think *anything* in programming is amenable to rote learning, much less testing. Writing good tests is an art, there are no hard and fast rules. Rules to to do it right is trial and error, and error and error, and perhaps a few more trials for good measure.<br>
<br>Alex<br clear="all"><br>-- <br>"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)<br>"The people's good is the highest law." -- Cicero<br>
<br>