[dom_hutton]

> It will make your evaluation a game where the student challenge is not understanding the concept of the class, but instead, understanding the rules of the various test you put in place.

I agree with most of what you have to say, however you're arguing for replacing one 'game' with another. If the goal is not to understand the grading engine then by the same logic the goal is to understand what appeals to whom is marking it.

[maeln]

I do agree that you are replacing one subjectivity (the tests and tools rules) with another (the teacher view of what is a good code).

But the idea is that a teacher is not as strict as a tool and is not here to punish student, but to instead grade them fairly in order for them to see what they can improve, and provide assistance for them to improve on those point. Well at least in theory, its not that easy to do :) .

The main reason why I disliked automated grading was that, a lot of time, I could see that a student almost got the right answer, but either didn't have the time to finish, or made some small mistakes. A automated tool would have given him 0, the same grade that a student who failed to understand anything or didn't work would have had, which I see has highly unfair. He cannot have all the point, but he should have some.

Not valuing the work of students is the quickest way I found to demoralize student and ultimately have them fail the class. And this is the opposite of what a teacher should strive for.

[IggleSniggle]

That's exactly the point. There is more subjectivity and nuance, and the person marking it is forced to engage in a kind of dialog with the actual code and see it for itself instead of relying on some limited objective heuristic which has no capacity to understand the student and what the student is misunderstanding.