You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current bats tests pass without enforcing interaction with the server. One such solution is shown below where the client writes the information immediately after reading it.
while ((line = System.in.read()) != -1) {
System.out.write(line);
System.out.flush();
}
We could write extensive test that don't allow hacky solutions, but "easy-hacky solutions" like these are likely achieved by mistake rather than on purpose. Especially if the students are learning something brand new and all the tests passing is their indication of validating their code. If we can point out something like "You never connected to the server"(via failing tests if possible), we should be able to prevent any "easy-hacky solutions".
The text was updated successfully, but these errors were encountered:
At the moment there's no way to know if the client is even talking to the server. I'm not sure how the testing would work out, but it would be nice to have some sort of "conversation" where we know both parties were involved. If the server performed some sort of "complex" calculation or modification of the text sent to it, then it would almost certainly avoid honest mistakes like this.
I don't really see how to do this as long as they're making both the client and the server. If they can make the server, then they can hack around and fake things out.
If we made the server then we could presumably have it include some kind of cryptographic secret that they wouldn't be able to "fake out", but that would really change the nature of the lab. For now, we'll leave this well enough alone.
The current bats tests pass without enforcing interaction with the server. One such solution is shown below where the client writes the information immediately after reading it.
We could write extensive test that don't allow hacky solutions, but "easy-hacky solutions" like these are likely achieved by mistake rather than on purpose. Especially if the students are learning something brand new and all the tests passing is their indication of validating their code. If we can point out something like "You never connected to the server"(via failing tests if possible), we should be able to prevent any "easy-hacky solutions".
The text was updated successfully, but these errors were encountered: