MoreQARespect

7 ms·

31.
by MoreQARespect 8mo ago
>The basic premise of TDD, for those unaware, is that one first writes a unit test that verifies the expected behavior for some function No, not "some function". The tests should mimic the expected behavior of a scenario usin
32.
by MoreQARespect 9mo ago
Testing is probably my favorite topic in development and I kind of wish I could make it my "official" specialty but no way in hell am I taking a pay cut and joining the part of the org nobody listens to.
33.
by MoreQARespect 9mo ago
This paper has 7 references and 4 of them are to a single google blog post that treats test flakiness as an unavoidable fact of life rather than a class of bug which can and should be fixed. Aside from the red flag of one blog post being &g
34.
by MoreQARespect 9mo ago
Coz while devs with specialties usually get paid more than a generalist, for some reason testing as a specialty means getting a pay cut and a loss in respect and stature. Hence my username. I wouldnt ever sell myself as a test automation en
35.
by MoreQARespect 11mo ago
no, but i have a feeling i should write one because i keep running into this misunderstanding. it makes it really hard to recommend TDD when people believe they already know what it is but are doing it ass backwards.
36.
by MoreQARespect 11mo ago
>Imagine someone developing an application where the standard C library was replaced with a stub implementation… That wouldn’t work… Yet TDD says one should be able to do pretty much the same thing… No it doesnt say you should do that.
37.
by MoreQARespect 11mo ago
>Reminds me of TDD bandwagon which was all the rage when I started programming. It took years to slowly die out and people realized how overhyped it really was. It never really went away. The problem is that there is a dearth of teaching
38.
by MoreQARespect 1y ago
>Most developers just don't know how to think in terms of formal proofs Formal proofs are useful on the same class of bug property tests are. And vice versa. The issue isnt necessarily that devs cant use them, it's that the pro
39.
by MoreQARespect 1y ago
1. Write test that generates an artefact (e.g. picture) where you can check look and feel (red). 2. Write code that makes it look right, running the test and checking that picture periodically. When it looks right, lock in the artefact whic
40.
by MoreQARespect 1y ago
Yes it is. Until the artefact which has been visually validated is locked in it is still a broken test. You can argue semantics until you're blue in the face it still follows red-green-refactor and it confers the same benefits as TDD.
41.
by MoreQARespect 1y ago
The reason why property testing isnt used that much is because it is useful at catching tests only for a specific type of code which most people arent writing.
42.
by MoreQARespect 1y ago
I have. I call it snapshot test driven development. You put the preconditions in, generate and record the graphics as an artefact at runtime and when it looks right, freeze it.
43.
by MoreQARespect 1y ago
I sincerely hope aliens dont end up being space americans. earth has oil and wmds.
44.
by MoreQARespect 1y ago
I find it's better to write the kind of tests you can generate docs from. It doesnt go out of date and you dont have to keep checking it for hallucinations. Better to save AI for tasks where it's less damaging if it screws up.
45.
by MoreQARespect 1y ago
Yeah, possibly. Privacy related services are often used by spammers.
46.
by MoreQARespect 1y ago
From reading that my guess would be that the IP of your host gotten from your hosting provider had some spammy history before you started hosting your blog on it. Either that or your DNS provider hosts a lot of spam.
47.
by MoreQARespect 1y ago
Hermetic e2e tests (i.e. ones that can run offline and fake apis/databases) dont have that problem so much. They also have the advantage that you can A) refactor pretty much everything underneath them without breaking the test, B) test
48.
by MoreQARespect 1y ago
>I'm not doubting you _could_ break up any PR into a shorter one. But that's kind of the point of an expert: they recognise what makes sense to do in reality I have seen plenty of huge PRs which were more trouble than they were
49.
by MoreQARespect 1y ago
>Not couldn't - but shouldn't, such as when there's tight coupling across many files/modules. No, this is a pretty classic example of where you can break up the work by first refactoring out the tightly wound coupling
50.
by MoreQARespect 1y ago
Give me one example then. One is all it takes to disprove a rule. Im fairly sure that I could explain how to break up any long PR in a sensible way. Parent thinks couldnt be done, so do you - what is an example? The only exception i can
51.
by MoreQARespect 1y ago
The "mid levels who consider themselves senior" are the exact type of people who I see saying what you're saying, i.e. * Yes, TDD on production code is nice in theory, but it doesnt work in my case . * Yes, short PRs are nic
52.
by MoreQARespect 1y ago
1. Documentation driven development - write the explanatory docs before the feature or project in markdown. 2. hitchstory for executable tests that generate up-to-date how to docs with screenshots or whatever. I tend to write all how to d
53.
by MoreQARespect 1y ago
This happens to me too it just happens roughly 100x less than me needing to know how to test properly. It's never the other day it's 10x a day, every day. So, OP is still correct.
54.
by MoreQARespect 1y ago
>fails to demonstrate how code-tests result in objectively better code. Tests give the freedom to refactor which results in better code. >So, testing has its place, but testing is really no better than simulation Testing IS simulation
55.
by MoreQARespect 1y ago
What's interesting about his engineering is that he used to obsessively make models of the cathedral to "spike" his ideas. They show this in the museum. One of the most waterfall projects of all time actually had a fair bit o
56.
by MoreQARespect 1y ago
You seem to believe that it's a side effect of code fetishism. Cant think why, but ok.
57.
by MoreQARespect 1y ago
>Which is why I used to find the debates about TDD or tabs/spaces silly. Does this provide faster iteration or more stability/maintainability to solve a real world problem? if it does, great. I mean, yeah. IDK why you find that
58.
by MoreQARespect 1y ago
This article grumpily skewers its own thesis at the top: >This indeed makes TDD less ridiculous. >However, even though I didn’t address this.... (perhaps he should though?) Inside out TDD (what he talks about) fails horribly, outside
59.
by MoreQARespect 1y ago
I tend to find that those bugs are in the extreme minority. Most flakiness ends up being a bug in the test or nondeterminism exhibited by the code which users dont actually care about.
60.
by MoreQARespect 1y ago
The way some programmers treat test flakiness is weird. With other types of bug programmers want to fix it. With flakiness they either want to rerun the test until it passes or tear it down and write an entirely different type of test - as

More ›