At this point it’s less about technology and more about network effects. If I go to an open source cloud document service it’s mainly about the tech, but if no users are on your food delivery app, no restaurants will bother using it, so no users will come.
The right tool here is tests at a level higher than machine code instructions that have been in CPUs since the 70s. Maybe TDD practice is not to test at this level, but every example of TDD sure tends to be something similar!
Either way gets me to a passing test, but I prefer the latter because it enables me to write another failing test.
But you could just write that failing test up front. TDD encourages you to pretend to know less than you do (you know that testing evenness requires more than one test, and you know the implementation requires more than some if-statements), but no-one has ever made a convincing argument to me that you get anything out of this pretence.
Tests should make changing your system easier and safer, if they don’t it is typically a sign things are being tested at the wrong level
TDD is about writing (a lot of) unit tests, which are at a low-level. Because they are a low-level design-tool, they test the low-level design. Any non-trivial change affects the low-level design of a component, because changes tend to affect code at a certain level and most of those below it to some degree.
When faced with a failing test, you make it pass as simply as possible, and then you summon all your computer science / programming experience to refactor the code into something more elegant and maintainable.
Why bother making it pass “as simply as possible” instead of summoning all that experience to write something that don’t know is stupid?
TDD doesn’t promise to drive the final implementation at the unit level
What exactly does it drive, then? Apart from writing more test code than application code, with attendant burdens when refactoring or making other changes.
I don’t want unseeded randomness in my tests, ever.
Seed the tests, and making these pass would be trivial.
As the existing reply stated, there are only ever finitely many tests.
My issue with TDD is that it pretends to drive the final implementation with tests, but what is really driving the implementation is the monkey at the keyboard thinking, “testing for evenness should be done with the modulo operation,” not exhaustive tests.
This is what Test Driven Development looks like
Shouldn’t the engineer be a bit more worried if the cable’s been cut?
If UDP drops packets it’s probably nothing. If TCP drops packets it’s because something’s actually wrong.
If you’re using TCP and losing packets you should be panicking though, because something is very wrong…
If you’re hosting it, prepare to get sued out of existence!
And here I was typing out iso-8859-1 like a scrub to make sure I wasn’t misremembering the encoding when doing the analogous thing in python…
Their employees have failed Unicode college >:(
They don’t have anything to do with alphabets in theory of computation…
So… UTF-8 interpreted as ISO-8859-1? You have failed Unicode college >:(
OCaml allows you to specify return types, but doesn’t force you to.
Yeah but it doesn’t cross function boundaries so it’s more limited.
The joke is that almost everyone calls them vegetables because the botanic categorisation of parts of plants is niche jargon that is not useful in everyday life, whereas the culinary categorisation is useful, and so your shopping list correcting you is worse than unnecessary.
Bad AI