31–40 of 53 posts
We're running a fork that supports a "sidecar" server for running multiple integration tests against. So if any tests that need the server are included, it spawns the server, runs the integration tests, and then shuts it down. By re-using the same server we speed up our runs tremendously.
Discussion thread on gh: https://github.com/nextest-rs/nextest/discussions/3330
Earlier quoted context omitted.
This is from the Kubernetes saying of "treat servers like cattle, not pets". Of course, some people like me keep cattle as pets, but then again I also name my servers, even the virtual or containerised ones.
It’s a horrible saying in that context also.
It got the point across, at a time where most people basically acquired servers, kept them until they died, and he was trying to push a development workflow where you constantly close("kill")/bring up new servers.
Thanks for posting about this! I'm the main author of nextest, and it represents my best foot forward for how Rust testing should be done. Happy to answer questions though I might be a bit intermittent.
Big fan of nextest and this is my first time seeing this site. I'll be real I feel a bit ridiculous commenting this but you might want to consider rephrasing this: >Treat tests as cattle, not pets. Detect and terminate slow tests. Not sure saying, "hey, treat your tests as an animal you can kill at will" paints the right image.
Thanks for posting about this! I'm the main author of nextest, and it represents my best foot forward for how Rust testing should be done. Happy to answer questions though I might be a bit intermittent.
Thanks for posting about this! I'm the main author of nextest, and it represents my best foot forward for how Rust testing should be done. Happy to answer questions though I might be a bit intermittent.
Big fan of nextest and this is my first time seeing this site. I'll be real I feel a bit ridiculous commenting this but you might want to consider rephrasing this: >Treat tests as cattle, not pets. Detect and terminate slow tests. Not sure saying, "hey, treat your tests as an animal you can kill at will" paints the right image.
Thanks for posting about this! I'm the main author of nextest, and it represents my best foot forward for how Rust testing should be done. Happy to answer questions though I might be a bit intermittent.
Hey, I love nextest. But, perhaps because of the one-process per test approach, endpoint security solutions like CrowdStrike Falcon or Palo Alto Cortex tend to make computers hang whenever tests kick-in. I would love if you were able to introduce a workaround, because none of those companies will fix their stuff. I am guessing a possible mitigation would be to have stagger the first invocation of any large test binar…
Earlier quoted context omitted.
Big fan of nextest and this is my first time seeing this site. I'll be real I feel a bit ridiculous commenting this but you might want to consider rephrasing this: >Treat tests as cattle, not pets. Detect and terminate slow tests. Not sure saying, "hey, treat your tests as an animal you can kill at will" paints the right image.
This is from the Kubernetes saying of "treat servers like cattle, not pets". Of course, some people like me keep cattle as pets, but then again I also name my servers, even the virtual or containerised ones.
Earlier quoted context omitted.
It’s a horrible saying in that context also.
I mean, I like animals too, but in context it does make sense. The context was to treat them as "obtainable yet ultimately killable entities you keep as a group, not individuals", which cattle pretty much is. Unless you consider keeping cattle as draft animals, but I think that stopped being the main purpose a long time ago. It got the point across, at a time where most people basically acquired servers, kept them un…
seems like `cargo nextest run` just runs `--lib` tests by default? however, `cargo test` is not so slow if you do `cargo test --lib`. how do I get nextest to execute the doc tests, too?
Earlier quoted context omitted.
I mean, I like animals too, but in context it does make sense. The context was to treat them as "obtainable yet ultimately killable entities you keep as a group, not individuals", which cattle pretty much is. Unless you consider keeping cattle as draft animals, but I think that stopped being the main purpose a long time ago. It got the point across, at a time where most people basically acquired servers, kept them un…
IMO, "make your servers fungible" is a better way to express the intent: slightly shorter, no metaphors, although "fungible" is a less common word. Maybe that's just me. (Edited to add: "make your tests fungible" has I think the wrong connotation; I think the original wording on the blog is about test executions -- and "make your test executions fungible" does seem like a good goal, similar to ACID guarantees for dat…