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

11–20 of 62 posts

Re: Just write a test for it

#11

Post by bschwindHN »

bsaul wrote: post #3

Sidenote : i found this code quite readable. I'm usually reading Rust code here on HN that's full of weird lifetime annotations or Dyn or super long generic types. As a non-rust dev this freaked me out. How common is this kind of code in practice ?

If you're running something like this and it isn't performance sensitive, you don't really need to deal with lifetimes at all. Lifetimes mostly come into play if you want to work with zero-copy parsing, or structs that borrow some things and act like a sub-view into the data you're working with.

I'm sure there are plenty of other use cases for lifetimes, but they don't come up very often when writing standard "application" code.

Re: Just write a test for it

#12

Post by bravetraveler »

swombat wrote: post #8
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.

Not even that long, but I agree on the "underwhelming"... "Oh I found some niche issue that bothered me and wrote some code to fix it." -> HN Front Page

Virtue trifecta; Rust, testing, and "just"

Re: Just write a test for it

#13

Post by dreghgh »

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.

Re: Just write a test for it

#14

Post by _dain_ »

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.

There's a difference between intellectually "knowing" that you can parse SQL, and actually going out and trying it and finding that it's practical to do in a test suite. I found the article valuable.

Re: Just write a test for it

#15

Post by dmit »

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.

The author mentions that approach at the end of the post:

> Apart from parsing the SQL query, I also considered an alternative testing approach that I might implement in the future: go through each migration one by one, and insert some dummy data into the database before applying it, to make sure that we test each migration being applied on a non-empty database. The data would either have to be generated automatically based on the current database schema, or we could commit some example DB dataset together with each migration, to make sure that we have some representative data sample available.

Re: Just write a test for it

#16

Post by nikolayasdf123 »

just look at this test for this one-liner DDL. the test is way more complex than thing it tests in first place. such confusing and hard to write and read tests is the reason people avoid writing tests in the first place. make tests great again!

(great = simple, short, easy to write, read, maintain. at very least no more complex than the thing it testing!)

Re: Just write a test for it

#17

Post by vlovich123 »

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.

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

Re: Just write a test for it

#19

Post by wesselbindt »

nikolayasdf123 wrote: post #16

just look at this test for this one-liner DDL. the test is way more complex than thing it tests in first place. such confusing and hard to write and read tests is the reason people avoid writing tests in the first place. make tests great again! (great = simple, short, easy to write, read, maintain. at very least no more complex than the thing it testing!)

Totally with you on the merits of simplicity, writability, readability. But I'm getting strong "rest of the owl" vibes. How would you have prevented this defect instead, in a way that you find simple?

Re: Just write a test for it

#20

Post by ptx »

vlovich123 wrote: post #17
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.

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?
Post reply on HN