> Actually the compiler checks cover most of the things I’d normally unit-test, so this is probably the only non-trivial project I wrote without checks and I’m OK with that.
This is interesting. First time I read about Rust I had this gut feeling that it's design might reduce the number of unit testing cases. Someone care to comment on that?
Just to add some context, here are the tests which I didn't write, but would in Python/Flask usually:
- Proper behaviour if I don't pass a parameter. Not needed, because it's an explicit `Option<>` which I have to handle.
- Is results list constructed properly / what's the None-vs-empty behaviour. Not needed, `Vec<>` is verified at type level and None is not possible.
- What happens if various database functions don't find a result. Not needed, because type signatures force either a returned `Entity` (if it's not there, it's an implementation bug: panic + 500), or `Option<Entity>` which again needs to be explicitly handled.
But these are only unit tests. If it was a critical app, I'd still write functional / logic tests to make sure the right data goes all the way to the database and back in known scenarios. Types can't guarantee that.
One kind of tests I'm tempted to write is for templates rendering properly, because handlebars-iron takes parameters as Json - all type guarantees go out of the window there. But it may be the same amount of effort to migrate to some type-safe templating like Maud.
I'm a Python/Flask dev who has knowledge of the basics of Scala. Which web framework and ORM would you recommend to develop a (potentially) non-trivial web app?
This is true IME. There are a lot of things you don't need to check for. Some guaranteed by Rust. Others guaranteed by the APIs themselves; Rust gives you a lot of powerful tools for designing APIs with static checks. For example, if you return a Result<T>, you don't need to check if the programmer forgot to handle a failure mode in your tests. The mode will be handled, or there will be an explicit panic.
Rust is harder to get to compile, but a lot of your boilerplate testcases go away. And if you design your API right, even higher-level guarantees can be provided statically.
A lot of times when writing Rust code in Servo I'll just ensure that stuff compiles, and then run the tests once before making a pull request. When contributing to python codebases I generally make smaller, incremental changes and run tests.
Edit: Just to clarify, this doesn't mean you should go all #yolo and abandon testing entirely. But (a) you can do so temporarily without adverse effects, and (b) once you start, you'll find that you only need to focus on the higher level tests.
I've dabbled with rust, but did quite a bit of stuff in haskell.
A lot of unit testing is verifying failure modes. What happens if they pass in null? What happens if they ask for a value i don't know about? stuff like that. Haskell (and rust) give you a lot more control over what a function is willing to accept at compile time.
You could spend your time writing a test to ensure null is handled gracefully. With rust, you have a bit more power, and you can simply ensure the function can't be called with null. It's more general than just null checking, but that's the flavor of what happens.
That's my general feeling as well. Coming from Scala transition into "dabbling" with Rust was actually quite smooth. I try to stick to functional style where possible, exhaustive pattern matching, everything wrapped in Result/Option, etc - eliminates the need of unit testing in many cases.
This is interesting. First time I read about Rust I had this gut feeling that it's design might reduce the number of unit testing cases. Someone care to comment on that?