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
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.
The text was updated successfully, but these errors were encountered:
djmitche
changed the title
27.2 Points and Polygons
Include suggestion to comment out test cases
Oct 10, 2023
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.
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.The text was updated successfully, but these errors were encountered: