For me, 60 is a very large class. Let me focus on a course design, extrapolated from other areas, in my case, the compiler course. The intent here is to make assessment feasible, rather than to say how to do it explicitly.
I would have two projects for the course. The first is individual and lasts two weeks. It would be to extend a framework that I provide and when completed would contain in the simplest way, the elements required for the larger project. It would count for a small portion of grading. But, I'd have to actually grade it. To make this feasible, I'd have them high light all changes from my base code.
The second project is done in teams. I'd choose the teams so that the total number is reasonable. Maybe five people per team, giving you about a dozen projects being done at once. I would also specify this project and possibly supply some base code giving a framework. Each team works separately on the project in parallel. It isn't a division of a larger project, but a "competition" of teams working on the same thing. With everyone working on the same project structure, I only have one thing to think about when grading.
I'd give them clear instructions about now NOT to manage their projects. No "dividing up the work" for example. Everyone is responsible for every part. I would try to convince them that dividing the work is actually more work for everyone since they need to integrate at some point. For beginners this is almost always a bad thing to do.
I would teach them how to run an agile team using something like XP. Iterations can be weekly or every other week. In particular, no one is permitted to commit code that only they worked on, avoiding the "prima donna" problem. I've had the teams name themselves, or I've named them, to build esprit d'corps: Fire, Ice, Wind, ....
I would also want to look at their code, but I now have a more reasonable work load. I would, again, have them highlight any changes they make from previous versions and include all past work (along with my comments) whenever they turn in the next iteration. It is now easy for me to see their progress. Each team turns in a folder each iteration.
I would (probably) require public demos of the projects at the end of the course, with each team having a few minutes to show their results. I normally require that everyone participate in the demo, but with five members per team it might be impossible.
I would use peer assessment within each team to get an idea about how people behave when not under my view. Peer assessment is always positive. "What is the main contribution of each team member? What is your own chief contribution?". Actually I usually, for a team of five, would have everyone give positive assessments of each of the top three contributors. If no one labels "jimmy" as a top contributor, I learn something. If everyone mentions "jimmy" I learn something else. But a positive assessment is more likely to be accurate and avoids the problem of people not wanting to say negative things about their friends.
Everyone gets the same grade on the big project unless there are serious reasons to do otherwise.
I have sometimes created (randomly) a "leader" of each team. The leader is not a manager, but is simply my main contact with each team so that I can get and give feedback when necessary. Try to do interventions early, if needed.
I usually use an asynchronous communication mechanism (a mailing list) so that anyone can ask a question at any time. I encourage others to answer questions as well as ask them, so I don't need to answer every question.
The goal is to reduce the load to a manageable level and still give individual feedback periodically. I haven't tried to automate grading in any way, but just made the scope of my problem more feasible.
Most of the course grade would be on the second project not the final exam (if any).
I could either use face time for lectures, or I could flip the classroom, letting the teams work together in lab and providing "content" through videos or readings done after hours. With a flipped design, I get to monitor each team in real time.
I can run unit tests on Java and C# to make sure the code students are submitting is correct without an issue
I can write code that does what it's supposed to, passes every test, and will still be flagged as a massive issue in any reasonable code review (if you want an example, remove all newlines and tabs from your code and rename your variables to randomized 15 letter strings). Am I to infer from this that your lessons do not include readability of code? Because if readability was a lesson focus, quite obviously you should try to (and be able to) read your students' code as well. $\endgroup$