Hacker News Reader

Comment by norman784 | Hacker News Reader

Also rust offers you out of the box tests, so you can write tests to prove your code does what you'd expect, before finish the whole prototype, it helps a lot versus most languages, most of the time you can just run `cargo watch -q -c -x test` and start hacking.

View on HN

Python has had tests and a cli that discovers them since 3.2 https://docs.python.org/3/library/unittest.html

>>Test Discovery¶ >> >>New in version 3.2.

It's invoked by:

>>python -m unittest

Edit:

I guess if you're argument is for the watcher...great but I use `entr` https://github.com/eradman/entr when I want that feature and it just works across languages but I've not used continuous testing for ages.

How are Rust tests any more suitable for rapid prototyping than Python tests? If writing tests can even be considered "rapid prototyping".

You cut down a chunk of tests by not needing to figure out what type something is. You can also use assert! and assert_eq! in your main code without even using tests which also cuts down on tests, where applicable.

You can also write unit tests in the same files as your main code. Eventually you'll want some kind of test suite when your codebase gets big enough, but it works well enough that you don't need to if you don't want to (for a small codebase).

Frameworks like Axum also of course support testing - for instance this crate lets you quickly mock up your server without having to do much: https://docs.rs/axum-test/latest/axum_test/

> You cut down a chunk of tests by not needing to figure out what type something is

I have literally never written such a test in a rapid prototyping context.

When you are prototyping you change code here and there, so a type system helps in that regard and I consider type system as a kind of test. So by having that built in, you need to write less tests, but AFAIK python has an optional type system, not sure how that works, but I suppose it would help in that regard.

If find that exactly the situation where a type system is intrusive, not helpful.

Many other languages have similar easy ways of running tests on file changes.

For example, in (Node)JS, you can just do `npx jest -o` if you are using Jest testing library, and with Scala you would usually use `~ test` in sbt shell.

This is likely just a me problem, but I always found Jest extremely annoying to set up with React and TypeScript - particularly with attempting to follow the documentation for jest and then failing spectacularly (in spite of using React Testing Library, jsdom + jest).

Cypress on the other hand I found to be really, really good

Cypress and Jest aren't really operating at the same level though. Cypress competes more with Playwright (functional, E2E tests), and Jest competes more with Vitest, Chai, Mocha, Jasmine for unit tests (though it can also do much more).

Personally I prefer Vitest to Jest... if it will work for the codebase I'm in.

vitest, like everything to do with vite, just works. The API is almost identical to Jest so you can swap over easily.

That's not the same thing, I think he's referring to the fact that in Rust you can keep unit tests and code in the same file, and strip them away at build time. That's not a thing in the js world (and most other languages), where tests must be in a different file and you are forced to export functions to test them, even if you wanted to keep them private in that file.

To be honest you might be able to use just the built in node test runner (deno and bun also have their own test runners), but IMHO are not as ergonomic as Rust, in Rust you can test private functions in the same file, and that let's you prototype faster, you write a simple function and a test (even when the prototype is not fully functional).

In JS land you could do the same I think, but you would need to export all methods that you want to test and they are in other files, and to make things worse you need to setup Typescript to make your IDE more useful and also write less tests, I would argue that in that case vite/vitest will be more helpful because the tests runs with the same config as the bundler, but still, it does not work out of the box as Rust, there might be other languages that have also good ergonomics as Rust in that regard, but none of the languages that I use besides Rust do that.

Reply on news.ycombinator.com