When I took programming classes in the past, the professor would specify what the function/method/CLI was supposed to look like and then use that to check results using a framework of their design. A big theme was that you should be able to program to a specified API without knowing who was calling you and give the correct result.
There would be sample inputs and outputs, for example "bar is 10 with the following four inputs", e.g.
So your automation would just need to put your test case driver and the student's code in the same place and call them, or modify the path, etc. I also agree with Daniel that avoiding input is generally a better way to do programming. If they want to run tests interactively, that's fine, but it's far easier to do things like
bar = foo(0,0,0,0)
bar = foo(1,3,4,5)
bar = foo(10,10,10,10)
bar = foo(-4,5,0,1)
and just check that the output is correct rather than entering it manually every time. It also opens the door to using other input methods (GUI, the interactive prompt, some other program, an instrument, etc)
It would probably be a good idea to run a diff of each file versus all the others and catch the especially lazy cheaters.
I also agree with Jan that it's important to critique and review the code. Design review is a very real part of engineering, and they should get used to having other people review their code for aspects that are difficult or impossible to check automatically -- maintainability, readability, ease of debugging and so on.