Nonsense. I unit taste all the time, it's called taste driven develoment (TDD) for a reason.
You can't unit test for taste
111–120 of 157 posts
Re: You can't unit test for taste
#112Earlier quoted context omitted.
I'm not familiar with shaders and game engines, so I'm not sure what you are saying. I had a quick look at godot tests, and seems to me they cover some parts of the shaders? Anyway, I was more wondering who/how people are dogmatic about TDD, and manage to leave out one out of three core concepts from red/green/refactor ?
If I cannot write shader code without broken tests, there is a bunch of yak shaving to make testing possible in first place, and that only covers a small subset of graphics pipeline features. It also takes zero consideration for the interactive nature of games/graphics development.
yes, there is some yak shaving necessary to make writing tests possible.
There is often a tension between delivering fast and high quality/bug free and what is necessary for medical software or financial calculations might not be necessary for games.
The question of whether to write tests at all is not really about TDD though.
Re: You can't unit test for taste
#113Exactly 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.
yup and I find it weird that people still remain so defensive of the Church of TDD even against empirical studies that show its limited benefits https://arxiv.org/abs/2602.07900
This study seems to be mainly about the value of vibe coded tests and not at all about TDD.
Perhaps unsurprisingly it found that vibe coded tests suck. As a card carrying member of the "church of TDD" (I do think it is practical), this is an empirical result I certainly would agree with.
Re: You can't unit test for taste
#114The thing I struggle with wrt to taste is that LLMs just don’t get it. Even if I write down every single thing it did wrong and how I’d do it, and even if I turn those into rules, it will know how to follow these specific rules, but for some reason it can’t seem to generalize beyond that. And the real list of rules seem truly infinite.
[deleted]
Re: You can't unit test for taste
#115Earlier quoted context omitted.
Apple's human interface guidelines says that some things can be written down though. It's a very thurough look at UX and while they don't adhere to them perfectly themselves, it's very much a north star to a some ideals. You can't unit test for taste, but you can integration test that bad tastes haven't happened.
I think Apple lost a bit of credibility after the round-corner fiasco that still persists on Tahoe.
Apple lost all credibility in UI around the time they introduced colorful vomit instead of app icons.
Re: You can't unit test for taste
#116Re: You can't unit test for taste
#117You 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't unit test for taste if you haven't written down what you mean by taste. If you can externalize it, then you can.
If you can externalize it, you only captured the small part of taste that can be externalized in concrete rules.
You can of course pretend anything else doesn't exist, like a person denying anything that can't be measured by their instruments.
Re: You can't unit test for taste
#118Earlier quoted context omitted.
Many such churches. Substitute static typing for TDD in your comment, and it will remain equally valid statement.
Static typing is very useful and time saving. I can rename something, knowing my IDE can propogate the change. I can call a function and know what it expects, not just "a thing, hope they added a comment so I know what type/shape wont blow it up!". Here I am talking about the basic static typing, and maybe some generics use occasionally, but obviously people also go overboard sometimes with type features and that hin…
Appreciating that there are some benefits is differwnt from adhering to the church
Re: You can't unit test for taste
#119You 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…
Pattern language sites / books have existed for years. The right approach is more work out what shared patterns are, make sure a bunch of reasonable ones are post trained into the models so that it's easy to refer to them by name (e.g. "tim pope / chris beams style commit messages", or "make invalid state unrepresentable") and then you're in a world where you can define your personal tasted through labels rather than…
But pattern languages don't encode taste they encode known working solutions. Making invalid state unrepresentable is not a matter of taste it's a best practice.
Re: You can't unit test for taste
#120Earlier 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…
I feel this, especially with the crazy lengths people go to mock things sometimes. A couple years back I was having a discussion with a friend/former coworker about testing (I was griping about unnecessary mocks I had to deal with for something at a job causing unnecessary extra work), and he asked how I would approach trying to get full unit test coverage instead. I was taken aback and said that I wouldn't try to ge…
Yeah.
Some TDD-obsessed companies will write tests in a way that requires you to spend a half hour understanding the web of mocks in order to update the tests to account for even a minor datastructure change. Coincidentally, your code change would cause those same tests to fail if they weren't mocked out, but they all pass until you make your changes to the mocks. This shreds the "if the tests pass, the change is probably correct" confidence that's most of the reason for having automated tests.
I am not a fan of this style of test writing.