Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Just write a test for it

kobzol.github.io

Post reply on HN
Print view View original

31–40 of 62 posts

Re: Just write a test for it

#31

Post by jononor »

IanCal wrote: post #25
ptx wrote: post #20

Earlier quoted context omitted.

Does it need to be done at each step, though? Couldn't the test data be added at just one point (where the schema is known) and just let it run through all the subsequent migrations to see if it goes boom?

Ideally imo you'd have a property based test that does the following: Perform some arbitrary list of valid actions. (This alone is valuable) Run the new migrations. Perform some arbitrary list of valid actions. Assert no crashes/errors. I've found this great for testing APIs - just "perform some list of user actions and make sure things don't explode" can catch a lot.

I have also found this kind of approach very valuable. With defensive code, where the code itself does a bit of the kind of correctness checking that one might conventionally put into tests, it works even better. Pre/post- conditions in functions for example.

Re: Just write a test for it

#32

Post by kubb »

karparov wrote: post #22
kubb wrote: post #10

Earlier quoted context omitted.

It’s actually a great reminder that a good framing and sales pitch matter a whole lot. The author isn’t just recounting their story, they’re selling it as a lesson in a generic approach that will make you a better engineer. Whether they can deliver on that promise doesn’t matter. It’s the feeling that’s clickable.

Tbf, it's not their fault it made it to the HN front page. Are we going to criticise every little innocent blog post just because somebody liked it, submitted it to HN and it got enough upvotes?

I don’t see a problem with making polite observations about aspects of the content that makes it to the top.

Re: Just write a test for it

#33

Post by formerly_proven »

ptx wrote: post #20
vlovich123 wrote: post #17

Earlier quoted context omitted.

The author correctly notes the challenge of correctly populating some pre-migration data at each step.

Does it need to be done at each step, though? Couldn't the test data be added at just one point (where the schema is known) and just let it run through all the subsequent migrations to see if it goes boom?

Normally you have per-migration tests for non-trivial schema migrations at minimum...

Re: Just write a test for it

#34

Post by nkrisc »

karparov wrote: post #22
kubb wrote: post #10

Earlier quoted context omitted.

It’s actually a great reminder that a good framing and sales pitch matter a whole lot. The author isn’t just recounting their story, they’re selling it as a lesson in a generic approach that will make you a better engineer. Whether they can deliver on that promise doesn’t matter. It’s the feeling that’s clickable.

Tbf, it's not their fault it made it to the HN front page. Are we going to criticise every little innocent blog post just because somebody liked it, submitted it to HN and it got enough upvotes?

If this isn’t a place to discuss the submissions, what is it?

Re: Just write a test for it

#35

Post by nurettin »

dreghgh wrote: post #13

This is the wrong approach. He should be putting data in the database schema before trying to run migrations on it. Doing that is simple and can potentially catch all sorts of bugs, including the bugs you didn't think of yet. His solution is complicated but only catches one very specific type of bug.

Writing a populate script for every migration sounds like a huge overkill.

Re: Just write a test for it

#36

Post by conradludgate »

I'm obviously biased by being an employee, but this is where Neon's branching[0] functionality can come in useful. We hope to expand on it one day and build more first-party migration tooling but you can already get a good enough system with the features we have.

Neon Branches are zero-copy snapshots of the database, with all the same data, on an isolated postgres instance. You can run migrations on that data without risking any modifications to data or performance in production. You can set up scripts to run it in CI[1].

This isn't perfect. If performance matters, some migrations might hide table locks which can cause major slowdowns. I'm not sure how you might detect this currently, I had some discussions recently about whether we can add "explain analyze" to DDL queries in postgres.

[0]: https://neon.tech/docs/introduction/branching [1]: https://neon.tech/docs/guides/branching-github-actions

Re: Just write a test for it

#37

Post by null_deref »

Enjoyed the article. Am I out of touch or have the article linked to a PR of the rust-lang eco system that didn’t go through a CR, is this really the standard for such a large language standard library?

Re: Just write a test for it

#38

Post by simonw »

null_deref wrote: post #37

Enjoyed the article. Am I out of touch or have the article linked to a PR of the rust-lang eco system that didn’t go through a CR, is this really the standard for such a large language standard library?

You mean this one? https://github.com/rust-lang/bors/pull/251

If you look at https://github.com/rust-lang/bors it's not a standard library package, it's a tool to support the Rust development process. And the person who opened and landed that PR is the lead developer of that project.

Skipping a code review from someone else feels OK to me for that.

Re: Just write a test for it

#39

Post by dxdm »

dreghgh wrote: post #30
vlovich123 wrote: post #17

Earlier quoted context omitted.

The author correctly notes the challenge of correctly populating some pre-migration data at each step.

You should solve the problem you need to solve, not the problem you have a cool solution for. The problem to solve is "given my database in an arbitrary but valid state, applying a migration should succeed and leave the database in a equally valid state". Not "how do I stop people adding NOT NULL columns into tables".

You're just over-generalizing the problem into something you will not be able to solve by proving that a migration works for a _specific_ arbitrary state.

Re: Just write a test for it

#40

Post by simonw »

kleiba wrote: post #5

This is a whole ̶l̶o̶n̶g̶ blog post about someone who was surprised that he could use a crate to parse SQL queries in Rust. A bit of an underwhelming read to me personally.

If someone figured out how to do a neat thing, learned some tricks along the way and wrote about it just in case it was useful to someone else - that person is doing useful work. More people should do that.
Post reply on HN