Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You can't unit test for taste

dev.karltryggvason.com

Post reply on HN
Print view View original

81–90 of 157 posts

Re: You can't unit test for taste

#81

Post by pjmlp »

valvar wrote: post #68
bob1029 wrote: post #37

Earlier quoted context omitted.

The biggest flaw I've seen with TDD is the fact that correctness does not compose upward. Every time two units come into contact, you've got an entirely new kind of unit. The tests from constituents do not cover emergent properties of the new things. You will repeat this same exercise the entire way up to the top, and the moment you come into contact with the customer (they want to change everything), the house of ca…

TDD is perfect for bugs; codify a replication first, then fix it.

Example for HLSL graphical glitch?

Re: You can't unit test for taste

#82

Post by pjmlp »

e12e wrote: post #72
pjmlp wrote: post #27

Exactly one of the reasons I never went down with all the TDD dogma of only writing code to fix broken tests. There is a reason conference talks are always about plain algorithms and data structures.

> TDD dogma of only writing code to fix broken tests. Isn't red-green-refactor pretty ingrained in TDD? Only write code to make a failing test pass; then refactor while making sure the tests still pass? Then write a test that fails, repeat?

Now do a games engine with that approach regarding shaders and the desired visuals.

Re: You can't unit test for taste

#84

Post by pjmlp »

MoreQARespect wrote: post #70
bob1029 wrote: post #37

Earlier quoted context omitted.

The biggest flaw I've seen with TDD is the fact that correctness does not compose upward. Every time two units come into contact, you've got an entirely new kind of unit. The tests from constituents do not cover emergent properties of the new things. You will repeat this same exercise the entire way up to the top, and the moment you come into contact with the customer (they want to change everything), the house of ca…

That is a flaw with unit tests written at far too low a level, not with TDD. You would have the same problem if you wrote tests like that after the code. TDD has no opinion about the level at which you wrote your test, it just assumes it's the correct one. This is the number one biggest misconception about TDD which I keep seeing repeated on hacker news. https://news.ycombinator.com/item?id=46810793 https://news.ycom…

TDD for UI effects?

Re: You can't unit test for taste

#85

Post by Jensson »

jayd16 wrote: post #32
chantepierre wrote: post #8

Earlier quoted context omitted.

Yeah you're right, I hear it more like "this is a week long hike, not a sprint" as if a marathon included rest. In any length of racing there's no tomorrow. But I'm doing tongue-in-cheek pedanticness here and will stop that right now !

In a marathon, not sprinting is the rest.

No its not a rest, marathon runners are still exhausted at the end, they can't go and run another marathon right after.

Re: You can't unit test for taste

#86

Post by MoreQARespect »

pjmlp wrote: post #81
valvar wrote: post #68

Earlier quoted context omitted.

TDD is perfect for bugs; codify a replication first, then fix it.

Example for HLSL graphical glitch?

https://hitchdev.com/hitchstory/approach/snapshot-test-drive...

set up a rendering profile and preconditions that generates a minimal snippet of images/video using a predefined GPU profile.

then test for either a pixel perfect reproduction of the correct behaviour or for the properties you're looking for (if it doesnt reproduce deterministically).

this is one way. i also subscribe to the view that if the type system is modified to become stricter in such a way that it can fail reliably in the presence of this type of bug that this is also good enough.

some people might argue that these arent "strictly" TDD by some definition but they set out a path to follow red green refactor and confer identical benefits so my view is who gives a duck?

I don't have enough domain expertise to know which variant of these approaches is best but I'm enough of a TDD expert to know that what you're implying isnt possible is actually something you would would probably derive a lot of value from if you did it.

Re: You can't unit test for taste

#87

Post by kalli »

Gosper wrote: post #15

Language count is a decent notoriety signal though pretty coarse. The OP/author should take a look at QRank: https://qrank.toolforge.org/ > QRank is a ranking signal for Wikidata entities. It gets computed by aggregating page view statistics for Wikipedia, Wikitravel, Wikibooks, Wikispecies and other Wikimedia projects from https://github.com/brawer/wikidata-qrank/blob/main/doc/desig...

OP here, that looks really neat, thanks for the link!

Re: You can't unit test for taste

#88

Post by MoreQARespect »

pjmlp wrote: post #84
MoreQARespect wrote: post #70

Earlier quoted context omitted.

That is a flaw with unit tests written at far too low a level, not with TDD. You would have the same problem if you wrote tests like that after the code. TDD has no opinion about the level at which you wrote your test, it just assumes it's the correct one. This is the number one biggest misconception about TDD which I keep seeing repeated on hacker news. https://news.ycombinator.com/item?id=46810793 https://news.ycom…

TDD for UI effects?

snapshot test driven development again. i already wrote a similar answer in response to your other comment.

it follows the definition of TDD and it works really well (with some caveats) but again some people get hung up on what their impression of TDD is (e.g. unit tests checking to see if a car object has a steering wheel or whatever...) rather than what it actually is and what about it is that actually works.

Re: You can't unit test for taste

#89

Post by ChrisMarshallNY »

hombre_fatal wrote: post #79
ChrisMarshallNY wrote: post #35

> but it ended up merely in a supporting role This has been my experience, as well, but it’s a really big support. It just needs adult supervision. I can’t understand how vibe-coded apps, actually work. As far as “taste,” goes, I test my stuff constantly, checking for even minor “friction points,” sometimes, refactoring back to design, in order to resolve issues that many folks would ship. I’m pretty anal, and want m…

> I can’t understand how vibe-coded apps, actually work. With a better process. e.g. plan->revision cycles, better instructions/docs like an ADR system. I don't think vibe-coding is relegated to "build me reddit but with blockchain" and then it's done. I think it instead describes the workflow where the software impl stays opaque but you evaluate the end product as an end user to step the product forward. It basicall…

That sounds excellent.

I have not encountered anything like that, with my Swift (native iOS) apps, but am pretty close to it, with my backend PHP.

I suspect that it depends on the tech stack. So far, the Swift output closely resembles that of a very inexperienced, but smart, engineer; One that has read up on all the "tips and advanced tricks" you can do with Swift, but has never shipped anything substantial. I need to really keep a close eye on it.

Re: You can't unit test for taste

#90

Post by vinay_ys »

trjordan wrote: post #4

You can't unit test for taste if you haven't written down what you mean by taste. If you can externalize it, then you can. Follow this line of thinking, and the AI-friendly answer is easy: we just have to externalize everything we know, so Claude can implement what I want. Except that I can't fully externalize myself. Debugging a system takes more resources than running the system. If I could write down everything I…

You can externalize the things you consider as taste by writing down generalized statements, but those statements need boundary conditions and exceptions to be also specified. Except, exceptions have exceptions and when to apply the rule vs when to use exception is contextual judgement. so, whatever residual that cannot be explicitly and unambiguously and generally spelled out, we call it as taste/judgement.
Post reply on HN