3 ms·
Expect is cool, I have used it in the past as well as the expect perl module, but in my opinion is always a suboptimal way to automate things. When I was a gra
by stcredzero 10y ago
Expect is cool, I have used it in the past as well as the expect perl module, but in my opinion is always a suboptimal way to automate things.
When I was a graduate Comp Sci TA in the 1990's, it was the perfect way to automate grading the Unix shell that the Systems Software class was supposed to write. Effectively, I was also writing a regression/functional testing system for the class. I explained that the Expect/Tcl script was going to be used to grade their project, and I provided the code.
One of my students said I was the best TA ever! There were a few students who complained that they shouldn't be marked off for a feature breaking, because it had worked a week or two ago. There were a few students who never figured out that the script was going to be used to grade their project, even though I provided weekly email updates explaining this.
- vram22 10y agoNice use of expect. I expect (pun intended, though realized after the fact) that you used it to simulate sending user input to their shell? and checking that the shell's response was as expected? (not doing the second on purpose either, honest, it just seems the right word to use).
- schoen 10y ago> I explained that the Expect/Tcl script was going to be used to grade their project, and I provided the code. If it's deterministic, is there a risk of someone just writing a second Expect script (instead of a solution to the programming exercise) that interacts with yours and gives the replies that you want?
- stcredzero 10y agoSure, but I didn't necessarily say that I'd give them the final version of the script and all of the tests.
- schoen 10y agoOh, I see!
- pfranz 10y agoI've taken online classes where they give you unit tests that use one set of inputs/outputs, when grading they'd use the same tests, but have a different set of inputs/outputs. Early on there was one or two cases where subtle problems came up because the public set and private set accidentally tested things slightly differently, but the TA / prof was quick to respond.
- 8_hours_ago 10y agoI had a C class in college where we submitted homework with a program on a server. The program would compile the C code, run it with a bunch of inputs, and then report back if it passed (i.e. the output matched the expected output). The output was expected to be in exactly the correct format, so the submit program would helpfully print your output and the expected output so you could fix any formatting issues. I got about 2 assignments into the class before I realized that I was being a chump. I wrote a C program that simply printed out the expected output, and submitted it. I received a passing grade on the assignment, so I took it further. I wrote a Perl script which would submit "int main(void){return 0;}", read the expected output, generate a C file that printed out that output, and submit it again. Apparently the TA for the class never checked the submitted assignments and relied entirely on the submit program, so I was uncaught for a few weeks. My downfall was trying to make the Perl script as efficient as possible (I had extra time on my hands because I didn't have to do the C assignments!). I had run my Perl script a few dozen times while optimizing it, and apparently the TA received an email every time an assignment was submitted. He brought it up to the professor and I was called into his office. Luckily he was lenient and let me just redo the assignments :)