The status quo, globally, is inequality and suffering for many. What a pathetic way of thinking that this must be defended with violence. It's unthinkable for you that this could be balanced out a bit more?
I was delighted to see this on the front page. Letter forms fascinate me and I enjoy playful explorations of the topic. They sit neatly between formal and informal systems and shed light on human cognition.
I'm very glad you're not the gatekeeper of what's here and what isn't.
Nobody is saying that. HN content typically caters to a prticular kind of geeky intellectual curiosity - that I think often has broader interests than you're giving it credit for.
As someone else pointed out this post would fit nicely into Douglas Hoftadter's Metamagical Themas - a book with impeccable geek credentials.
Thought the same, copy-pasting valuable blocks as a reference into a comment worked fine. If it exceeds a one block rewrite, make small dirty commits to keep track of things.
On one hand it's nice that there are tools to support devs who get lost in their undo-redo history, on the other I feel like it's a matter of good habits to not even have this problem.
of course changing habits is hard, so maybe tooling is justified in this case. I'm just happy I don't have nother "history" type mental model to deal with.
I "got" reduce not long ago. It's occasionally handy, and it makes sense, but sure, it should not be overused. It is the most complicated between the three.
A good old loop in code bases that are not afraid of them are totally fine and probably clearer in many cases.
Been through this process. Thing is, when you have a <Heading> component, you might as well simply write a css module for that component. Tailwind is great for "fast prototyping" and quickly styling a bunch of static HTML though. Wouldn't use it for a larger single page app.
I might be overreacting to past projects, but I've almost always found bespoke css gets out of control. Most projects tame it with well defined values for margin, padding, etc, and applying and enforcing those values means you sort of end up creating your own Tailwind. The "atomic" side of Tailwind is nice, but so is the consistency in values it provides.
If I was to take the css module approach today, I might still find myself using Tailwind and @apply inside the modules.
> why should anyone care about someone else’s test architecture, of all things. As long as you neither under- or over-testing, why on earth does it matter?
If you have to maintain tests written by other devs you might start to care. Devs apply different patterns to writing tests and show different amounts of discipline doing so. Some produce lots of duplication ("it doesn't matter, it's just a unit test"), others prefer a complete setup and tear-down before and after every little assertion. I've seen things..
I've seen unit tests that test around bugs. Once you fix the bug, a lot of tests fail. Then you discover there is no easy fix for the test. Either delete them all or replace them with new ones.
The fake is coupled to the "real" implementation of the interface. But the test that uses the fake is no longer coupled to the implementation of the fake/mock.
Instead of counting how many times a method is called (mock), your test just gets to test the outcome of the overall operation (fake).
That's an expectation which is an extra optional layer on top of mocking. The important difference between mock and fake is that a separate mock has to be created for every single test, but a fake needs only be created once for all tests that use the faked dependency.
Because they don't just implement a part of the interface (just one store method, or just one of two load methods). They try to create a fully functional fake of the original class.
In this case instead of storing the blobs via a REST interface or a database connection, it just keeps it in memory. So it should mostly behave like the real implementation, but is not suitable for production, as it doesn't persist the data.
The only things that are missing there are real life latency or maybe exceptions because of connectivity issues.
> Because they don't just implement a part of the interface (just one store method, or just one of two load methods). They try to create a fully functional fake of the original class.
So shouldn't fakes have their own tests as well? Mocks don't need tests (at least in C# with a framework) because no new class is ever written.
Anyway most of these issues are inherently linked to the nature of OOP and are a direct trade off to its benefits.
Both Mocks and Fakes have advantages and drawbacks, but the OP doesn't reflect that.
I wish articles written on that subject would take a step back and explore how code can be written so that the burden of testing is reduced to a minimum.
On the best scenario, your fakes just replace some standard components your have on production with other standard components, and keep everything else equal. On those cases, no they don't need tests. But when you are doing something weirder, they pretty much do.
On the best scenario, your mocks are just data that doesn't have timing characteristics, don't react to the system being tested, and are short enough to not need any kind of compression (in loops or gzip). On those cases, they don't need tests. But if you are doing anything weirder, they pretty much do.
I honestly don't see any sense in separating them in categories like if they had discreete non-overlapping mono-dimensional properties.
Anyway, why do you claim any of that is specific to OOP?
And in what paradigm do your programs consist of only pure functions? Certainly not on FP, where IO is explicitly added to a lot of code.
Anyway, there isn't much difference between mocking a unity and passing some static data into your functions and comparing the results with the expected ones.
In one case you create the class on your own, in the other case the mocking framework does that for you on the fly. With both approaches you can do very basic or very complicated things.
Or do you have a rule in your company that every class needs a test? Maybe this rule is the problem.
because no new class or method is created with mocks, it's merely declarative, no new logic is created than needs to be tested. Fakes very much have logic since they are implementations of classes.
> Or do you have a rule in your company that every class needs a test? Maybe this rule is the problem.
No Fakes are, not the fact that every unit should be tested. Fakes are very much a unit, the fact that they are classes is irrelevant.
To put it differently, mocks aren't tested because they can't be wrong, be at they are "not even wrong". You have to have faith that mock behavior is actually a reasonable emulation of the real system, without ever checking. The weakness is that your tests of the system under test don't help you find flaws in how the system under test uses the lower level dependency, because you are simply forcing the lower level dependency to behave the way you wish it would.
> It may also appear that the details we have to take into account here are not that different from the implementation-aware assumptions we were making when using mocks, as neither are actually governed by the interface of the component. However, the major distinction is that the coupling we institute here is between the test double and the real implementation of the component, rather than between the test double and the internal specifics of its consumer.
Ok, so the implementation-awareness lies in the fake itself, not the code setting up mocks. But creating the fake is part of testing, if you follow this approach. So you're still doing implementation-aware testing in the end. Don't get me wrong, fakes are a cool idea. But the article is overselling their advantages a bit I think.
Some books explicitly claim to teach you a specific skill. And some people have that general expectation towards books. This is what the author criticizes, as I understood their points.
Generally, books that attempt to teach a specific skill will be full of exercises. If you read through the book methodically (not like reading a novel) and do all the exercises, I would be shocked if you did not learn that skill.
I guess a lot of people don’t do that. They skim through a textbook like it’s a boring novel and they make a few notes or they highlight everything or they fill the poor book with sticky notes in a multitude of colours. Anything but doing the exercises! And then is it any wonder why they forget everything a year later?
Yeah of course, if I'm already in the process of acquiring some skill, willing to do all the exercises, look up what I don't understand somewhere else, etc., I will learn that skill and the book will help and be a good foundation or guideline.
But the point remains: Just reading the book, as in consuming page after page, is not enough.
None of the mentioned books teach specific skill through. And I had success learning new skills from books, but those books were meant to teach that skills. They were not among top popular, because for whatever skill you have in mind, only few people actually want to learn it at the same time.
Not that all book that claim to teach skill actually teach it, but plenty of them do.
