Ttdfjt

I've been teaching Java and C# for years and I'll be picking up a web development (HTML, CSS, JS) course in the fall semester because our department is down a faculty member and won't be filling the position.

I can run unit tests on Java and C# to make sure the code students are submitting is correct without an issue, but I don't know how to efficiently assess websites. My school uses Cengage for curriculum delivery and their MindTap product does assessments, but I don't want to rely on that for the primary driver in class for a number of reasons.

How can I efficiently and effectively assess student work other than reading through all their code and observing every web page? There has to be some tool out there that I can work with to do an initial sweep for me... right?

Much less detail than the excellent post by Buffy, but directly to the question. Replace unit tests with validations and linters.

Have the students create all content in distinct files: HTML, CSS, and JS. Any styles or JavaScript in the .html file is invalid for the project(s). There are many validators and linters for all three, as well as for any other "code" you choose to use/allow, such as PHP, Ruby, etc.

Since a unit test only gives go/no-go results, a validator is at least as effective. A visual check of the resulting page/site shouldn't take but a few moments as well. If it validates and looks correct, it must be "right."

If you also wish to instill, or enforce, coding standards, comments, indentation, etc., a linter may help.

Running a series of validators and linters, checking the operations of the page/site, and visually scanning the code should take much less time than grading a paper-based exam, so you are still time ahead. If the students are provided access to similar tools, if not the exact ones, or exact settings you use, they can develop the habit of applying the "test" to their own code as part of their development work-flow.

As an extra note, if you need to compare versions/iterations of their code, you can use a system such as git, which need not be based on GitHub, or even use remote repos at all. Each student can be required to create a GPG key for their project work, and sign their commits. With that system, you can use the built-in diff function to see the changes and be certain who committed what.

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.

Assessing web dev courses at scale can be tricky because you have to consider the following:

• ensure that the resulting web app looks as expected


• all functionalities should work as expected with the correct logic
  


• the code quality to make everything work should meet the industry standard

With 60 students (or any number over 20 really), this can get really tricky.

My recommendation would be to find tools that help you do the following:

• Asses the looks: You should be able to preview the submission without downloading and running anything locally (CodeSandbox)


• Correct logic: Either run E2E tests and/or unit tests (Puppeteer, Jest)


• Code quality: linters (ESLint)

I would also recommend giving a try to AutoGradr that does all of the above in a single tool and is built specifically for educators such as yourself. (Disclaimer: I'm the author of this free tool)