Hacker News Reader

Comment by rgoulter | Hacker News Reader

> ... I think the snarky code purity response here ...

I think if we can agree "taking on tech debt can be a good approach" and has dignity, we also have to agree that wishing for code without tech debt is also dignified.

:o) Which is perhaps why the "I_suck_and" gets removed from this property.

> If the API can be misused I think ... the API is flawed, and the underlying mechanism that requires "misuse" ought to be fixed.

Which in this case would mean "minitest should only be able to run tests in random order". -- I think having an (inconvenient) option as a concession is a reasonable trade off.

View on HN

The context here is that Ryan Davis added test order randomization as a default feature to minitest, which was meant to be a mostly-compatible drop-in replacement for the old Test::Unit. Some people complained a lot about this and requested a flag to turn it off. I remember this being hashed out over some time on the ruby-talk mailing list:

https://rubytalk.org/t/minitest-randomization/60387/3

I think the straw that broke the proverbial camel's back was that Rails had order-dependent tests at the time. So Ryan added the flag, with his reluctance reflected by the mildly insulting name and doc comment.

> we also have to agree that wishing for code without tech debt is also dignified.

I think then my question is how to achieve this wish given the realities of the production of working code as demanded by business. Is this really a realistic wish? I am yet to work for a company that had code and didn't have technical debt. I am yet to hear of such a company.

> I think having an (inconvenient) option as a concession is a reasonable trade off.

Exactly. Perhaps these specific minitest devs ought to have called their library "i_suck_and_wrote_a_testing_framework_that_allows_writing_tests_that_are_order_dependent_and_also_its_called_minitest". :D

I find it completely unreasonable that you would blame the testing framework here. No, that line does not make sense. It does the opposite of make sense: they made a very reasonable concession and you want to call that sucking? No.

While code that needs this feature really does suck.

Hey! I guess they should have just written code that didn't necessitate the need for this method, in the first place! Oh well, everyone has their flaws! The question is if they need to write "I_Suck" all the time as penitence.

What necessitated implementing the method was that _other people_ were saying that random test order didn't work with their existing test suites (written for Test::Unit). Not only did the minitest author compromise and add this method for people unable or unwilling to fix their test suites, but he even wrote minitest-bisect to help debug ordering issues. I think this is more than enough from someone working as a volunteer on an open source project.

> Hey! I guess they should have just written code that didn't necessitate the need for this method, in the first place!

They did! It's not their code that necessitates it.

The only way you can say they necessitated it is by omission, as in "they didn't write the code to fill this need people have, therefore the need went unmet". But that would be nonsense because seven billion people are guilty of the same crime. No, it's the people that wrote the code under test that necessitated the need. And those people are not the minitest authors.

I think I get what you're saying! It's fine to write code that allows for and enables bad practices when it suits a pragmatic need. We therefore totally agree.

Yeah! But it also helps to discourage those bad practices in the future.

So when the minitest authors added this feature, they enabled the bad practices for a pragmatic need, and also did something to discourage it.

On the other hand, when the people wrote those tests, they weren't writing them that way to suit a pragmatic need. They were just making a mistake.

That's why the former doesn't suck, but the latter does suck. And the writers of those tests are not just enabling bad practices, they are directly performing the bad practices.

I see, so if bad practices also discourage their future usage, things are fine. So if someone writes a bad test and it makes code refactoring harder, things are fine! Perfect!

> So if someone writes a bad test and it makes code refactoring harder, things are fine!

I said it's good to discourage bad practices. Unless you think refactoring is a bad practice, you have understood my comment incorrectly.

But also you can remove the part about discouraging from the previous post, if it's confusing:

Minitest enabled bad practices for a pragmatic reason.

The tests were not following bad practices for a pragmatic reason, they did it by mistake.

Enabling is less bad than doing, and minitest had a reason while the bad tests didn't.

Therefore minitest doesn't suck and those tests do suck.

Edit: fixed a couple typos

I think we should probably go back to what I said at the very start: "I've noticed a lot of developers that have this kind of code purity complex where their way of doing things is superior even if the actual code Works - which I think is the number one most important thing about code."

So that's calling them wrong about whether the tests are bad. Okay, fine, you can have that opinion.

But there's no way to twist that around into "minitest devs are the ones that suck by their own logic".

Either nobody here sucks at coding, or some test-writers suck at coding. But those are the only two options that make sense.

> So that's calling them wrong about whether the tests are bad. Okay, fine, you can have that opinion.

What you're saying, is also just an opinion.

When I say that you can't turn their own standard against them, that is not an opinion. (Except in the "everything is an opinion" sense.) I'm asserting a fact about how words interact.

I'm sorry, if you don't think there are opinions about how words interact we really need to go back to fundamental philosophical basics here.

I do think there can be opinions, but if you stretch that enough then at a certain point you hit "everything is an opinion" territory and then it no longer matters if you call something an "opinion".

When I say your disagreement with them is an "opinion", I am not using that definition. I'm using a much more narrow definition. You have different ideas of what makes code good. Different preferences.

While my argument is not based on my preferences. When I called those tests bad I was just explaining the point. It doesn't actually matter if I think the tests are bad or not. Either way the minitest devs are absolved of their own criticism.

If you would like me to use a different word than "opinion", you can suggest one. The point is, please understand what I mean, and let's not argue about how to define words.

> The point is, please understand what I mean,

If misunderstanding is possible then clearly it's not simple to understand what people mean everytime. Maybe if you explained more clearly I'd understand why you feel your opinion is factual and feel what I say is just opinion.

> You have different ideas of what makes code good. Different preferences.

> my argument is not based on my preferences[...] It doesn't actually matter if I think the tests are bad or not.

The thing I am calling your opinion is not your evaluation of minitest. I'm saying your evaluation of the test code is an opinion. My evaluation of the test code is also an opinion.

Neither of our opinions about the test code matter here.

That was what I was arguing in this post: https://news.ycombinator.com/item?id=34831045

I don't think your attempt to turn things around into criticism of minitest is an opinion. I think it's snark that doesn't work when examined more closely.

This hn article is literally a link to minitest code.

Because it's unprofessional. Or to argue about whether the tests truly do suck.

Not because you can flip the standard around and say it sucks for those same reasons it accuses some tests of sucking.

The stuff you said up here: https://news.ycombinator.com/item?id=34829343

is just wrong.

You're arguing that me saying minitest authors should put "i_suck" in their library name is unprofessional, on this post?

It "sucks" because it has an inaccurate method name that implies an inferiority. This is my current and original criticism of the minitest devs.

Your idea that I am unprofessional, is an opinion.

"This method name indicates a lack of understanding that finding the right balance of speed, cost and quality is a compromise."

> You're arguing that me saying minitest authors should put "i_suck" in their library name is unprofessional, on this post?

No I am not.

I feel like you need to express your point better!

The minitest author(s) were unprofessional. That unprofessional humor is the main reason it was posted.

But that's different from writing code that sucks. A single flag name like that doesn't even affect functionality or readability.

It actually does, it's generally agreed that longer method names are worse unless the length is descriptive. This isn't a super contraversial idea.

Wishing for code w/out tech debt is naive; not dignified. It's just the lesser of whatever two evils were going on at the time the code was written.

Reply on news.ycombinator.com