(Comments blame it on UCRT, not .NET but… that doesn’t matter much to me.)
This is unfortunately an actual quote I got from Claude Code after having it write a unit test for me.
It ended up mocking the entire method it was supposed to test, resulting in the unit test essentially only testing itself.
Sometimes people manage it in which case it resembles a mini superpower but mostly they do not.
If it mirrors the spec then few people would change it to be wrong to make the test work.
I have only seen TDD used poorly, as a crutch, an alternative to thinking deeply about the problem space. If it can be done well I have not personally seen it. Perhaps SQLite, but such projects are an oddity.
To me tests at the spec level are largely user acceptance tests which are indeed very useful.
>I have only seen TDD used poorly, as a crutch, an alternative to thinking deeply about the problem space. If it can be done well I have not personally seen it. Perhaps SQLite, but such projects are an oddity.
Theyre not that odd. I've applied it to every type of code base I've come across.
>To me tests at the spec level are largely user acceptance tests which are indeed very useful.
Where I use TDD the tests are exactly like this - written at the highest level possible using a shared framework that integrates sophisticated fakes which carefully balance realism, speed and flakiness. They all follow roughly the same pattern across the code base and that pattern mirrors the spec scenarios.
Where I see TDD used by people who complain about it they usually think the idea is to write a test for a class because they're thinking about writing a class. It is generally taught badly.
That's it. It says nothing about the type of test you write. Personally i do it with literally every type of test that i write - acceptance, integration, unit.
If you write a decent test, yes, TDD is always valuable. If you TDD with shitty tests, not so much, but that isnt really an issue with TDD.
As far as I remember from days when I used Windows, the version of your visual studio (which has the compiler and standard libraries) was not related to the build of your operating system
One of the advantages of using proprietary packaged software is supposed to be a unified support and product.
In this case the maintainer redirects the issue to some other team and passes the ball as if it were an open source project with 50 dependencies with thin responsibilities "no, if there's an issue with a button, you should report it to GUI-button, we do GUI-form and we just pass the button generation to their library"
Finding the right contact even for employees inside the beast is challenging and a skill all its own.
They'll gladly harvest your data whether you like them or not!
I was simply stating fact, without any particular opinions on the matter of fault.
But that is way more normal for microsoft, because it's about redundant products that get merged eventually. What's not typical is internal dependencies being exposed, the case above were many MSFT teams/products in the same tier, the case in this article is many MSFT teams/products in a single vertical, at different tiers of the supply chain.
It's possible that this is more a feature of open source, this being an open source MSFT product (.NET core) and the report having been filed through an open source channel (github issues). I think that if the issue were submitted to some account manager or customer service rep through a channel linked to a paying customer account, the response would have been very different.
But you cannot expect a quality customer service response if there's no $ being paid to the maintainers. Whether it be Microsoft or whatever FOSS project.
That said, maybe a slight change like, "I'll open a ticket with the other team" instead of "you should open a ticket with the other team" makes all the difference. But like I said in another comment, if you open a ticket on github, you aren't paying for that support, you should aim to have a commercial relationship with Microsoft and then raise the issue through that commercial channel.
Otherwise you have no recourse to complain, you are getting everything as-is.
“Both Math.Pow and std::pow invokes the pow function in UCRT, which is shipped with Windows. The issue should be reported to MSVC instead”
It’s not the job of a bug reporter to figure that out and to verify that nothing goes wrong in setting up stuff for invoking that function or in getting its output back into the C# world.
That’s even more true because the dynamic nature of .NET code makes it far from easy to verify by inspection that that function is just calling the pow function in UCRT. The C# compiler might do constant folding wrong and there might be several ways in which the runtime compiles the CLR code (fast compilation to start running it quickly, slower compilation that produces faster code later if it turns out to be called a lot, etc)
The problem with the comment is it does not make ownership of the next steps clear. The maintainer should've either taken the ball ("I will report this to...") or made it clear that the reporter should hold the ball ("We can't fix this here. You should report it to..."). Instead they used the passive voice ("The issue should be reported to..."), which means no one owns it, which means it won't be done, which is a bad way to handle a bug report.
they didn't test that they just assumed that since they call a library function the library function must be the root-cause. This is classic bug-punting.
Bug reporter might not care that much and not bother opening another bug report, and this looks like a pretty bad bug.
Users report bugs to the team working on the user application. If the bug is actually in a component that application uses, then it's that team's responsibility to report it upstream, not the user's.
That some OSS devs don't work that way isn't really important in terms of this point. If the project isn't going to address the bug, they should just say so without implying the user did something incorrectly.
It's going to be interpreted BY WHOM to say that? Other .NET developers? Yeah, maybe, at least some of them. By the submitter of the original bug? No idea, I can't read their mind.
> No idea, I can't read their mind.
Mind-reading is not necessary to predict how people will react to certain patterns of behavior.
OP said it quite clearly and so did you: that it's the reporter's job. It's the maintainer's job to put in the bug report now.
I don't agree that it was stated clearly. That's the whole point of my comment. Leaving it unclear is bad, tasks should always have an unambiguous owner.
> It’s not the job of a bug reporter to figure that out
What’s ambiguous about this statement?
How you choose to resolve it is up to you. You might implement a fix in your code to handle the bug case until the dependency is fixed.
This is a broader cultural thing. In large organizations there is a tendency toward deflecting as much responsibility as possible onto other teams. In part it's a lack of resources, but it's also a result of individual contributors not being willing to take ownership of the product they work on.
Instead means "this isn't our bug, it's the underlying library."
The libraries you rely on are part of your product. You own the issues that bubble up from them.
A much much better reply for the maintainer would've been: "The root cause looks to be X, I'll submit a ticket and make sure a fix makes it into our build."
The comment isn't blaming the reporter for not doing that.
https://github.com/dotnet/runtime/issues/117233#issuecomment...
You’re quoting a community contributor and this is not a firm stance held by MS themselves. He should probably not have posted that because it’s misleading. They even have a tag to triage these kinds of issues.
I don't see how it gets past the test suite though.
It's like the first example you see when you start learning about unit tests as a concept.
For instance, with it, you can double the volume of a body by looking at it from a weird angle.
A lot of set-theory research is looking into the consequences of various axiomatic assumptions.
I really dislike how Discord is slowly eating up the web and being used as the primary channel for communication, when most of the community resources resides in their Discord, it makes it hard for me to find relevant information through the web thanks to Discords lock-in
I think it's _too_ social for bug reports and questions. I'd prefer a forum or GitHub issues for that kind of thing.
Or maybe I'm just getting old.
Surely math libraries and optimizations have been a solved problem for the last 20+ years.
I find it strange as well that no unit test caught this. Squaring a negative number is definitely a case I'd expect to be covered. Perhaps compiler optimization made this case work in the unit test, allowing the runtime function to break? And then it broken in .net where the JIT compiler is dumber than the C++ compiler?
debo_•15h ago
H8crilA•15h ago
lucaslazarus•15h ago
ARob109•15h ago
Tepix•14h ago
bee_rider•14h ago
hinkley•10h ago
sksrbWgbfK•14h ago
monkeyelite•13h ago
pas•5h ago
of course we also went from having no Rust and no TypeScript and only a few hundred thousand semi-academic people having some knowledge of programming to hundreds of millions of people doing some tutorial/bootcamp/cert/degree, or even built something, or actively learns, or right now works as a professional programmer.
(un)fortunately Ada was not able to grow to became the default tool for all these jobs that all those millions of people did or wanted to do when they did/do programming.
JS/ECMAScript is evolving, things are getting better!
tantalor•13h ago