Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include suggestion to comment out test cases #1340

Closed
djmitche opened this issue Oct 10, 2023 Discussed in #1267 · 1 comment · Fixed by #1073
Closed

Include suggestion to comment out test cases #1340

djmitche opened this issue Oct 10, 2023 Discussed in #1267 · 1 comment · Fixed by #1073
Assignees

Comments

@djmitche
Copy link
Collaborator

djmitche commented Oct 10, 2023

Discussed in #1267

Originally posted by @njr0 in #1267 (comment)
I suppose I'll add another comment (that potentially applies to several of the exercises).

The rust compiler errors are great, but quite long and numerous. I like exercise that consist of making tests pass (very clear and well defined!) but if you start by running the tests without doing any implementation, you get screeds of errors.

More importantly, if you start implementing things to make one test at a time pass, it doesn't work, because the code won't compile. I've written in a lot of compiled languages, but most of my test-driven development experience is in Python, where this is less of a problem. Of course, it is true that Python won't work if you have syntax errors, but the nature of rust is that a lot of things that would be run-time errors in a language like Python are compile-time errors. Even compared to other compiled languages, Rust's emphasis on safety means that more things fail at compile time than is the case with other languages.

So what I do is to comment out all the tests first and (at least for this exercise) everything then compiles OK.

(I actually tried this first on the web routing exercise, which went particularly badly because the URLs include */, so the commenting out with /* ... */ didn't work, and it took me a while to understand why. I guess that was pretty unlucky.)

Anyway, I'm not sure I'm recommending that you supply the code with the tests commented out, but I wonder if you should supply it with only the first one active and the others deactivate with #[ignore]. Obviously, you'd need to tell people to unignore the tests, but they could do them one at a time, which might be less overwhelming and (more importantly) allows you to do the implementation bit-by-bit.

@djmitche djmitche changed the title 27.2 Points and Polygons Include suggestion to comment out test cases Oct 10, 2023
@djmitche djmitche self-assigned this Oct 10, 2023
@djmitche
Copy link
Collaborator Author

I think this makes a lot of sense. It's probably best to include this suggestion in the first exercise that has test cases. The v2 work is rewriting a bunch of the exercises, so I'll do so once that lands.

@djmitche djmitche linked a pull request Nov 21, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant