←back to thread

Parse, Don't Validate (2019)

(lexi-lambda.github.io)
389 points melse | 7 comments | 26 Jun 21 07:23 UTC | HN request time: 0.308s | source | bottom
Show context
kortex ◴[26 Jun 21 14:15 UTC] No.27642049[source]▶
This principle is how pydantic[0] utterly revolutionized my python development experience. I went from constantly having to test functions in repls, writing tons of validation boilerplate, and still getting TypeErrors and NoneTypeErrors and AttributeErrors left and right to like...just writing code. And it working! Like one time I wrote a few hundred lines of python over the course of a day and then just ran it... and it worked. I just sat there shocked, waiting for the inevitable crash and traceback to dive in and fix something, but it never came. In Python! Incredible.

[0] https://pydantic-docs.helpmanual.io/

replies(8): >>27642308 #>>27642664 #>>27643276 #>>27643474 #>>27644758 #>>27645737 #>>27646367 #>>27647141 #
jimmaswell ◴[26 Jun 21 15:23 UTC] No.27642664[source]▶
I've found this to be simply a matter of experience, not tooling. As the years go by I find the majority of my code just working right - never touched anything like pydantic or validation boilerplate for my own code, besides having to write unit tests as an afterthought at work to keep the coverage metric up.
replies(5): >>27642800 #>>27642869 #>>27643369 #>>27643588 #>>27644097 #
cortesoft ◴[26 Jun 21 15:48 UTC] No.27642869[source]▶
Tests aren't to make sure your code works when you write it, it is to make sure it doesn't break when you make changes down the line.
replies(1): >>27644709 #
1. exdsq ◴[26 Jun 21 18:50 UTC] No.27644709[source]▶
How do you know your code works when you write it if you don't test it?
replies(3): >>27645375 #>>27645643 #>>27646387 #
2. syngrog66 ◴[26 Jun 21 20:10 UTC] No.27645375[source]▶
you run it. look at the results or output. like the stdout, or a file it changed, or in a REPL or debugger. depends on situation
replies(2): >>27645480 #>>27646224 #
3. chrisandchris ◴[26 Jun 21 20:21 UTC] No.27645480[source]▶
Yeah I‘m not sure that‘s how software engineering should work.

Tests should prove a desired behaviour. Sometimes it‘s not possible to fully run code until late in some staging, just because there are a lot of dependencies and conplexity. That‘s what tests are for (on various lebels of abstraction).

replies(1): >>27645651 #
4. cortesoft ◴[26 Jun 21 20:42 UTC] No.27645643[source]▶
Sorry, should have said “aren’t JUST to make sure your code works when you write it”

I was specifically responding to the commenter I replied to, who said they didn’t need tests because their code just worked the first time after he wrote it.

5. cortesoft ◴[26 Jun 21 20:43 UTC] No.27645651{3}[source]▶
I think it depends on the task. Some code we write is so simple and only used a few times that you don’t need tests.
6. exdsq ◴[26 Jun 21 21:49 UTC] No.27646224[source]▶
Sounds laborious to manually check edge cases each time you change that code or its dependencies. I'd rather just write a test.
7. globular-toast ◴[26 Jun 21 22:09 UTC] No.27646387[source]▶
You don't. But you only need to test it once (manually), then commit it.

You write automated tests so that you can keep running the tests later such that the behaviour is maintained through refactor and non-breaking changes.