Actually, test-driven development is a pretty decent analogy. Including the shortcomings of TDD, such as the fact that you pass the unit tests doesn't mean you have a working product, which in education translates as students passing tests but not being able to use the subject in real life.

You can reduce the delta between passing tests by writing more, better tests, but again you quickly run into a problem - you spend so much time on testing that you start to lose the time to actually learn / write the actual project code.

So that's some ways in which the analogy is good. But there are some glaring errors in the analogy. In education, a student can have perfectly mastered the material, but is just really bad at passing tests, getting stressed out by it. In TDD, you can make your test environment match the target environment very closely. For most student exams this isn't true - most applications of higher learning are not done in a race against the clock, and you always have access to the Internet to help you out when you're stuck. By their nature, tests can't validate your capacity to work in a team with any fidelity. So, some of the very important skills that are needed in the application of knowledge are very difficult to test, making tests less valuable as a means of judging a student's acquisition of skills. There's a reason why PhDs require a thesis and a thesis defence, rather than sitting an exam before they are awarded.