41–50 of 163 posts
Earlier quoted context omitted.
trust but verify translates to trust no one but don't be a dick about it
To me, it's rather a postcondition instead of precondition. Trust that a person will do the right thing, but verify that the right thing has actually been done.
How can you verify as a precondition instead of a postcondition? You can't verify anything until the act has been completed.
Earlier quoted context omitted.
If I had a dollar for each frontend test that actually don't actually test anything I would be able to retire by now!
Cargo cult testing. Some people don't understand the point of testing so they just go thru the motions and end up with something that makes no sense.
The post could also talk about yet another desirable paranoia, namely "Am I building the right thing?" - so talking to customers/clients/stakeholders/users is arguably one of the most important steps when seeking re-affirmation and controlling one's work. Nothing worse than people who think they understand a technical problem, but it's not the one that the customer wants solved...
Earlier quoted context omitted.
What's the meaning of "I trust you that the amount of cash you've given me is correct" when you then proceed to count it? If you're verifying, why do you need to say "I trust you"? A trustworthy and an untrustworthy person will get equally verified.
Has nothing to do with trust. I trust that you will give me the money. I also trust that you counted the right amount. But I still want to make sure you did not make a mistake.
This is a really useful mindset as a programmer, but backfires in real-life as it makes you an anxious person.
I guess you need to compartmentalise into different kinds of 'trust'. The not 'trusting' you do with a computer is different from the trusting you do with fellow humans in daily life. They just happen to use the same word in English.
Earlier quoted context omitted.
If I had a dollar for each frontend test that actually don't actually test anything I would be able to retire by now!
Cargo cult testing. Some people don't understand the point of testing so they just go thru the motions and end up with something that makes no sense.
I’ve written plenty of do nothing tests in my time to be sure that management regularly got a report of tests being added.
>> Random access of a character in a text buffer could take constant time (for ASCII) or linear time (for UTF-8) depending on the character encoding This is true, but incomplete. All unicode encodings take linear time, not just utf-8. That's because a character can contain multiple code points. Utf-32 allows for random access of code points in constant time, but not characters. Utf-16 has variable length code points…
Yeah, but the author was talking about ASCII. ASCII takes constant time.
ASCII does indeed take constant time - which I agreed with.
So, good article with a misleading title. Don't be paranoid.
[0] I don't consider 100% test coverage as anywhere near close enough for that.
> Failing tests indicate the presence of bugs, but passing tests do not promise their absence. If only :) Far too often I find myself working with tests that patch one too many implementation details, putting me in a refactoring pickle
Or even worse, tests that test implementation details that doesn't matter for the actual outcome.
When done with that phase and my API looks relatively functional, I remove all relatively trivial tests and I write bigger ones, often randomized and property-based.
This works decently well and you do not have an army of useless tests there hanging after the process is done.
Earlier quoted context omitted.
Or even worse, tests that test implementation details that doesn't matter for the actual outcome.
Used to be (perhaps still is) a nasty habit of Rails apps to have vast test suites covering every Active Record query they ever used (with fixed seeds to boot), rarely straying from giving the bog-standard and already very thoroughly tested and battle-scarred AR predicate builder a wholly unneeded workout; but none of their own front-end code because writing for selenium was too hard. But look! Thousands of tests and…
I've also seen plenty of tests that test if a template was rendered rather than if whatever thing it actually outputs was in the output. It is just calcifying the impementation making it hard to test.
But it is a tradeoff, and a hard one as well, because if you do all things all the time, combining all variations of database with all variations of the views, then you end up with a test suite that take forever to run. Finding the right tradeoff there has not shown itself to be very obvious, sadly.