1409
Tests are code too (lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
[-] toastal@lemmy.ml -4 points 1 year ago

If you use your type system to make invalid states impossible to represent & your functions are pure, there less—maybe nothing—to test, which will save you from this scenario.

[-] dustyData@lemmy.world 26 points 1 year ago

You can't have any bugs if you don't write any code.

[-] jjjalljs@ttrpg.network 15 points 1 year ago

Nothing to test? Lol what.

def add(a: int, b: int) -> int: return a * b

All types are correct. No side effects. Does the wrong thing.

[-] MyNameIsRichard@lemmy.ml 5 points 1 year ago

Maybe it's doing the right thing but is badly named

[-] magic_lobster_party@kbin.social 6 points 1 year ago

Maybe the it’s the English language that is wrong?

[-] dan@upvote.au 4 points 1 year ago* (last edited 1 year ago)

Old and busted: Fix the function

New hotness: Redefine enough words in the English language such that the function is now correctly implemented

[-] jmcs@discuss.tchncs.de 12 points 1 year ago

It must be nice to work only with toy cases where this is feasible.

[-] toastal@lemmy.ml 0 points 1 year ago

Nothing toy-like about using ADTs to eliminate certain cases. When all cases are handled, your tests can move from a micro state to a macro state. Contraint types or linear types can be used to only allow certain sizes of inputs or require all file handles be closed when opened.

Naturally if your language’s type system is bad you can’t make these compile-time guarantees tho. Heck, a lot of developers are still using piss-poor languages with null or the infernce sucks with any.

this post was submitted on 02 Nov 2023
1409 points (98.6% liked)

Programmer Humor

32501 readers
510 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS