10 years ago, someone wrote a test for servo that included an expiry in 2026

lluu about 21 hours ago 56 commentsRead Article on mastodon.social

ZH version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

48% Positive

Analyzed from 1435 words in the discussion.

Discussion (56 Comments)Read Original on HackerNews

vocx2tx•41 minutes ago

But still a kludge. Better: use something equivalent to Go's testing/synctest[0] package, which lets you write tests that run in a bubble where time is fixed and deterministic.

[0] https://pkg.go.dev/testing/synctest

dathinab•29 minutes ago

in general

- generating test data in a realistic way is often better then hard coding it (also makes it easier to add prop testing or similar)

- make the current time an input to you functions (i.e. the whole old prefer pure functions discussion). This isn't just making things more testable it also can matter to make sure: 1. one unit of logic sees the same time 2. avoid unneeded calls to `now()` (only rarely matters, but can matter)

andai•about 1 hour ago

Interesting, from the title I thought it was intentional, as a "forced code review." Apparently not, but now I really like that idea!

adrianpike•about 1 hour ago

We've done that at a few places I've been at - it's tricky because if the failure is too short its just annoying toil, but if it's too long there's risk of losing context and having to remember what the heck we were thinking.

Overall it's still net positive for me in certain cases of enforcing things to be temporary, or at least revisited.

Alupis•about 2 hours ago

Just skimmed the PR, I'm sure the author knows more than I - but why hard code a date at all? Why not do something like `today + 1 year`?

johanvts•about 1 hour ago

That introduces dependency of a clock which might be undesirable, just had a similar problem where i also went for hardcoding for that reason.

cogman10•34 minutes ago

There's already a clock dependency. The test fails because of that.

rcxdude•about 1 hour ago

Arguably you should have a fixed start date for any given test, but time is quite hard to abstract out like that (there's enough time APIs you'd want OS support, but linux for example doesn't support clock namespaces for the realtime clock, only a few monotonic clocks)

whynotmaybe•about 1 hour ago

Because it should be `today + 1 year + randomInt(1,42) days`.

Always include some randomness in test values.

zelos•5 minutes ago

Generate fuzz tests using random values with a fixed seed, sure, but using random values in tests that run on CI seems like a recipe for hard-to-reproduce flaky builds unless you have really good logging.

CoastalCoder•about 1 hour ago

> Always include some randomness in test values.

If this isn't a joke, I'd be very interested in the reasoning behind that statement, and whether or not there are some qualifications on when it applies.

dathinab•17 minutes ago

humans are very good at overlooking edge cases, off by one errors etc.

so if you generate test data randomly you have a higher chance of "accidentally" running into overlooked edge cases

you could say there is a "adding more random -> cost" ladder like

- no randomness, no cost, nothing gained

- a bit of randomness, very small cost, very rarely beneficial (<- doable in unit tests)

- (limited) prop testing, high cost (test runs multiple times with many random values), decent chance to find incorrect edge cases (<- can be barely doable in unit tests, if limited enough, often feature gates as too expensive)

- (full) prop testing/fuzzing, very very high cost, very high chance incorrect edge cases are found IFF the domain isn't too large (<- a full test run might need days to complete)

whynotmaybe•about 1 hour ago

Must be some Mandela effect about some TDD documentation I read a long time ago.

If you test math_add(1,2) and it returns 3, you don't know if the code does `return 3` or `return x+y`.

It seems I might need to revise my view.

rcxdude•about 1 hour ago

Not a good idea for CI tests. It will just make things flaky and gum up your PR/release process. Randomness or any form of nondeterminism should be in a different set of fuzzing tests (if you must use an RNG, a deterministic one is fine for CI).

dathinab•8 minutes ago

if it makes thing flaky

then it actually is a huge success

because it found a bug you overlooked in both impl. and tests

at least iff we speak about unit tests

whynotmaybe•about 1 hour ago

That's why it's "randomInt(1,42)", not "randomLong()".

devin•about 1 hour ago

Are you joking? This is the kind of thing that leads to flaky tests. I was always counseled against the use of randomness in my tests, unless we're talking generative testing like quickcheck.

dathinab•7 minutes ago

or, maybe, there is something hugely wrong with your code, review pipeline or tests if adding randomness to unit test values makes your tests flaky and this is a good way to find it

whynotmaybe•about 1 hour ago

`today` is random.

andai•about 1 hour ago

Interesting, haven't heard this before (I don't know much about testing). Is this kind of like fuzzing?

whynotmaybe•about 1 hour ago

I recently had race condition that made tests randomly fail because one test created "data_1" and another test also created "data_1".

- Test 1 -> set data_1 with value 1

- Test 1 -> `do some magic`

- Test 1 -> assert value 1 + magic = expected value

- Test 2 -> set data_1 with value 2

But this can fail if `do some magic` is slow and Test 2 starts before Test 1 asserts.

So I can either stop parallelism, but in real life parallelism exists, or ensure that each test as random id, just like it would happen in real life.

bombcar•about 3 hours ago

Any time constant will be exceeded someday.

An impossibly short period of time after the heat death of the universe on a system that shouldn’t even exist: ERROR TIME_TEST FAILURE

unkl_•about 3 hours ago

Posted on HN in 2126: 100 years ago, someone wrote a test for servo that included an expiry in 2126

jerf•about 3 hours ago

I've got some tests in active code bases that are using the end of 32-bit Unix time as "we'll never get there". That's not because the devs were lazy, these tests date from when that was the best they could possibly do. They're on track to be cycled out well before then (hopefully this year), so, hopefully, they'll be right that their code "won't get there"... but then there's the testing and code that assumes this that I don't know about that may still be a problem.

"End of Unix time" is under 12 years now, so, a bit longer than the time frame of this test, but we're coming up on it.

bombcar•about 1 hour ago

I seem to recall much smugness on Slashdot around the "idiot winblows users limited by DOS y2k" and how the time_t was "so much better". Even then a few were prophesying that it would come bite us eventually ...

yetihehe•about 3 hours ago

Now I feel bad for using (system foundation timestamp)+100 years as end of "forever" ownership relations in one of my systems. Looking now, it's only 89 years left. I think I should use nulls instead.

prerok•3 minutes ago

Well, it won't be your problem /j

fny•about 3 hours ago

Who here remembers the fud of Y2K?

jghn•14 minutes ago

As others have stated, the lack of visible effect is not the same thing as there never having been a land mine in the first place.

I can tell you anecdotally that on 12/31/2000 I was hanging with some friends. At 12PM UTC we turned on the footage from London. At first it appeared to be a fiery hellscape armageddon. while it turned out to just be fireworks with a wierd camera angle, there was a moment where we were concerned something was actually happening. Most of us in the room were technologists, and while we figured it'd all be no big deal, we weren't *sure* and it very much alarmed us to see it on the screen.

acuozzo•about 2 hours ago

Don't mistake a defused bomb for a dud.

https://en.wikipedia.org/wiki/Preparedness_paradox

arduanika•about 1 hour ago

Thanks! I think about this concept a lot, and now I know there's a name for it. "Preparedness paradox". I'll have to remember that.

And to your point, Y2K is right there on the wiki page for it.

philipallstar•about 2 hours ago

I remember the reality of all the work needed to avoid issues.

kjs3•16 minutes ago

Tell us you weren't involved in Y2K iwithout telling us you weren't involved in Y2K.

gom_jabbar•about 2 hours ago

Made me think of Mark Fisher's Y2K Positive text:

> At the Great Midnight at the century's end, signifying culture will flip over into a number-based counterculture, retroprocessing the last 100 years. Whether global disaster ensues or not, Y2K is a singularity for cybernetic culture. It's time to get Y2K positive.

Mark Fisher (2004). Y2K Positive in Mute.

LocalPCGuy•about 2 hours ago

While there was a lot of FUD in the media, there were also a lot of scenarios that were actually possible but were averted due to a LOT of work and attention ahead of time. It should be looked at, IMO, as a success of communication, warnings, and a lot of effort that nothing of major significance happened.

tejohnso•about 2 hours ago

Yes, Y2K is a success story, similar to the alert and response related to ozone layer and CFCs.

Dissimilar to the global climate catastrophe, unfortunately.

---

The 2024 state of the climate report: Perilous times on planet Earth

https://academic.oup.com/bioscience/article/74/12/812/780859...

"Tragically, we are failing to avoid serious impacts"

"We have now brought the planet into climatic conditions never witnessed by us or our prehistoric relatives within our genus, Homo"

"Despite six IPCC reports, 28 COP meetings, hundreds of other reports, and tens of thousands of scientific papers, the world has made only very minor headway on climate change"

"projections paint a bleak picture of the future, with many scientists envisioning widespread famines, conflicts, mass migration, and increasing extreme weather that will surpass anything witnessed thus far, posing catastrophic consequences for both humanity and the biosphere"

NetOpWibby•about 2 hours ago

Exciting times with an anticlimactic end; I was in middle school, relishing the chaos of the adult world.

myself248•about 2 hours ago

Another victim of the preparedness paradox.

samlinnfer•about 1 hour ago

i had to plant a 10 year time bomb in our SAML SP certificate because AFAIK there is no other way to do it. It’s been 7 years since then. Dreading contacting all the IDPs and getting them to update the SAML config.

db48x•about 20 hours ago

Classic!

But before you judge the fix too hashly, I bet it’s just a quick and easy fix that will suffice while a proper fix (to avoid depending on external state) is written.

pavel_lishin•about 2 hours ago

I'll bet you one US Dollar that this is a scenario where the temporary fix becomes the permanent one. (Well, at least, permanent for a hundred years.)

Some day, Pham Nuwen is going to be bitching about this test suite between a pair of star systems.

db48x•42 minutes ago

That’s one of my favorite books :)

I agree that it’s plausible!

em-bee•about 2 hours ago

of course it is just an easy fix. it's the kind of solution that even someone like me could write who has no understanding of the code a all. (i am not trying to imply that the submitter of the PR doesn't understand the code, just that understanding it is unlikely to be necessary, thus the change bears no risk.

but, the solution now hides the problem. if i wanted to get someone to solve the problem i'd set the new date in the near future until someone gets annoyed enough to fix it for real.

and i have to ask, why is this a hardcoded date at all? why not "now plus one week"?

kristofferR•about 2 hours ago

[flagged]

tomhow•about 1 hour ago

Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.

https://news.ycombinator.com/newsguidelines.html

andai•about 1 hour ago

It was started by people who thought Twitter didn't have enough censorship (back when it had a lot more).

I guess that's a matter of personal sensibilities, but it's pretty funny to me.

(Note: this is the only fact I know about it, happy to learn more.)

rirze•about 1 hour ago

Any social space will break down upon reaching a critical point in representation of the general populace.

I have no idea about the development however.

MBCook•about 1 hour ago

Worked for me.