Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
MoreQARespect
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
61.
▲
by
MoreQARespect
1y ago
Unit tests dont have a coherent agreed upon definition either. In fact, when I first saw Kent Beck's definition I did a double take because it covered what I would have called hermetic end to end tests. The industry badly needs new w
62.
▲
by
MoreQARespect
1y ago
Ive never in my life written a test for a sorting algorithm nor, im sure, will i ever need to. The bias most developers have towards integration tests reflects the fact that even though we're often interviewed on it, it's quite ra
63.
▲
by
MoreQARespect
1y ago
This is precisely the problem I alluded to which is solved by writing higher level tests with TDD that make fewer assumptions about your design. TDD ought to let you make a bad design decision and then refactoring it while keeping the
64.
▲
by
MoreQARespect
1y ago
TDD fizzled because not enough emphasis was put on writing high level tests which matched user stories and too much emphasis was put on it as a tool of design.
65.
▲
by
MoreQARespect
1y ago
It's pretty bad at this. It's much better used as a testing methodology than a design methodology. It can provide high level guardrails confirming implementation correctness that are as indifferent to software design as possible (
66.
▲
by
MoreQARespect
1y ago
I would usually measure "TDD correctness" in terms of how closely the test matches a user story vs how closely it mirrors code implementation. The former is desirable, not common. The latter is common, not desirable.
67.
▲
by
MoreQARespect
1y ago
>first the developer writes a failing automated test case that defines a desired improvement or new function If you TDD at the highest level that makes sense, with a test that mirrors the requirements in the form of a user story rather
68.
▲
by
MoreQARespect
1y ago
Most juniors I watch program very quickly get overwhelmed by complexity because they dont know how to follow strategies like BDD or TDD which isolate parcels of complexity (e.g. how the program is supposed to behave) from other parcels (e.g
69.
▲
by
MoreQARespect
1y ago
Astral doesn't really have a business model yet, it has potential business models. The issue is that there isn't a clean business model that will produce the kind of profits that will satisfy their VCs - not that there isn'
70.
▲
by
MoreQARespect
1y ago
The broader point was to make documentation a side effect of the work rather than a separate task. The opportunities to do this are not obvious but they are there. I imagine this principle can probably be applied to nuclear power plants too
71.
▲
by
MoreQARespect
1y ago
It works with Keiretsu. Ive long thought that this is how Europe should play catch up and build its own equivalent(s) of AWS, GCP and Azure.
72.
▲
by
MoreQARespect
1y ago
That's a valid goal, but they should have adapted the software to the community instead of trying to adapt the community to the software. SO's biggest asset was its community and while they treated it with some respect in the begi
73.
▲
by
MoreQARespect
1y ago
This problem can be solved by making documentation a natural side effect of the actual work. One way is by recording video calls where the decisions are made with transcriptions which can be interpreted by LLMs. Another is generating docs f
74.
▲
by
MoreQARespect
1y ago
Gherkin was always a pretty bad format that made it difficult to write terse, clear spectests. Inevitably the people who used it made horribly repetitive or horribly vague gherkin files that were equally bad for BDD and testing. This is an
75.
▲
by
MoreQARespect
1y ago
Companies of that size are served by the "enterprise call a salesperson" offering. If you really don't need all of the other features you can probably negotiate a discount.
76.
▲
by
MoreQARespect
1y ago
>The other thing about documentation is that it inevitably goes stale. Not if you generate reference docs from code and how-to docs from tests.
77.
▲
by
MoreQARespect
1y ago
>Like many Agile tools, it is completely broken when divorced from those organizational principles There is a narrative, pushed by its creators, that cucumber isnt broken it is just misused. It's a narrarive that needs to die. It is
78.
▲
by
MoreQARespect
1y ago
I find it sad that cucumber managed to pour so much cold water on the idea of readable spectests. It's like if we gave up on programming because COBOL was bad.
79.
▲
by
MoreQARespect
1y ago
>Oh I understand the standard arguments. I think the problem here is that you are substituting standard arguments for my arguments. >With some caveats, I think this is just a fiction. There can be some value in having high-level tests
80.
▲
by
MoreQARespect
1y ago
>If you don't accept that concept Nobody anywhere in the world disputes that unit tests should surround a unit. >IMHO, the sizing of components is context, language, and team dependent. But it really doesn't matter Yeah, tha
81.
▲
by
MoreQARespect
1y ago
>An actual specification layer isn't any simpler than the execution layer. The point of separation of concerns isnt to keep the simple layer separate from the complex one. It's to simplify the whole thing by only addressing on
82.
▲
by
MoreQARespect
1y ago
hitchstory. typed YAML over python.
83.
▲
by
MoreQARespect
1y ago
If the "unit under test" is low level then thats coupling low level implementation details to the test. If you're vague about what constitutes a "unit" that means youre probably not thinking about this problem.
84.
▲
by
MoreQARespect
1y ago
I use executable specs quite a lot with stakeholders. I'd never ask them to write them, but I will often write a spec/test based upon their two sentence jira and then screenshare and walk them through my interpretation to get fe
85.
▲
by
MoreQARespect
1y ago
The problem isn't really that the domain experts or business people aren't interested in reviewing these tests. The problem is that the cucumber language is just very, very poorly suited for writing anything beyond very basic spec
86.
▲
by
MoreQARespect
1y ago
I literally do the diametric opposite of you and it works extremely well. Im weirded out by your comment. Writing tests that couple to low level implementation details was something I thought most people did accidentally before giving up on
87.
▲
by
MoreQARespect
1y ago
>The majority of folks are consumers and unable and/or unwilling to handle the complexity of self-hosting The majority of folks just want to text and call on their phones. They are unwilling to handle the complexity of having an ent
88.
▲
by
MoreQARespect
1y ago
privacy and control are things which people dont tend to think about until: * online apps start doing something incredibly creepy (all of my non tech friends have a story like "how tf did they know me and my wife were talking about cru
89.
▲
by
MoreQARespect
1y ago
Self hosting reminds me of the world of smartphones just before the advent of the iPhone. Using a phone as a mini computer was possible. Downloading and using apps happened. I even used offline maps. It was still the preserve of nerds whi
90.
▲
by
MoreQARespect
1y ago
I dont think tests and types are the same "thing" per se - they work vastly better in conjunction with each other than alone and are weirdly symmetrical in the way that theyre bad substitutes for each other. However, Im convinced
More ›