I_suck_and_my_tests_are_order_dependent

Funny. At a previous employer, we had a few services that needed access to some data we hadn’t put behind a service yet. For bureaucratic reasons I won’t bore y’all with, our team wasn’t given the green light to create the needed service to provide access to the data, so a coworker and I created an endpoint on an existing service but we added a requirement that an oddly specific and undocumented HTTP header calling out management must be provided in every request made to the endpoint and then we waited. At some point, someone else needed to use the endpoint and came to us asking why it wasn’t working. We told him about the header. He was annoyed and complained to his manager. The very next week, we got what we wanted: Our new service was up and running! We also got into a bit of trouble over this, but that’s just an extraneous detail — haha.

A couple of related practices I&#x27;ve picked up over the years: (1) using long names when implementing things that are necessary but discouraged (2) putting dange_danger in names of things that should never be used in production.<p>The former introduces just a tiny bit of friction, but it&#x27;s often enough to encourage developers to use the preferred API calls.<p>The latter I learned almost 20 years ago from Google&#x27;s &quot;Mustang&quot; search back-end. If running a test instance of Mustang without bringing up a ton of dependency processes, there was a --danger_danger_must_not_fail true commandline flag (or something very similar) to turn a bunch start-up sanity check aborts into warning log messages. If any code reviewer sees &quot;danger_danger&quot; being added to production command line flags, they&#x27;ll almost certainly ask the right questions.

I&#x27;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. The code purity complex is a self-limiting decision.<p>Those developers will be sitting at home fuming, I guess, as I cheerfully build a new feature on VB6 code last changed in 1999 that relies on using &quot;On Error resume next&quot;, on an obscene contract rate.<p>Working only with Good code is a luxury decision, and writing Code That Sucks isn&#x27;t necessarily bad, if thats the fastest&#x2F;cheapest way to write code that works. The end user almost as a rule, doesn&#x27;t care about your code purity. A developer probably couldn&#x27;t even explain that purity in a way that would make the end user understand its value. This method name indicates a lack of understanding that finding the right balance of speed, cost and quality is a compromise.<p>Yes, tests that can run in isolation are &quot;better&quot;.

<a href="https:&#x2F;&#x2F;github.com&#x2F;rails&#x2F;rails&#x2F;commit&#x2F;e81f3c210eca074ed6227bd1c40835d44761c09e">https:&#x2F;&#x2F;github.com&#x2F;rails&#x2F;rails&#x2F;commit&#x2F;e81f3c210eca074ed6227b...</a>

Pytest has an equally deprecating option for a different &quot;use case&quot;:<p><pre><code> disable_test_id_escaping_and_forfeit_all_rights_to_community_support = True </code></pre> <a href="https:&#x2F;&#x2F;docs.pytest.org&#x2F;en&#x2F;6.2.x&#x2F;parametrize.html#pytest-mark-parametrize-parametrizing-test-functions" rel="nofollow">https:&#x2F;&#x2F;docs.pytest.org&#x2F;en&#x2F;6.2.x&#x2F;parametrize.html#pytest-mar...</a>

You&#x27;re a bad programmer. I&#x27;m a good test runner.

I have a method in our Java app`iKnowWhatImDoingGiveMeTheSession()` that will only work if you have set the system property `doYouReally=Yes, I really know what I&#x27;m doing`<p>It should never be used in production, but can be helpful to have available when doing certain kinds of investigation.

I wrote an unsafe library at a FAANG and used similar naming conventions.<p>The init function was named along the lines of “MyClassName_UNSAFE::initUnsafeIUnderstandTheRisks()”<p>And the library itself was called something like “library-name-unsafe-my-team-name-must-approve-diff”<p>So anyone trying to use it would have to add a library with that name to their list of dependencies and would come to us asking for a code review, and more than half the time we would redirect them to a safer alternative (valid use cases for the unsafe library were few and far between).

MySQL Command line has a flag called i-am-a-dummy, I know it&#x27;s supposed to be funny but I think it&#x27;s actually a good idea to run in dummy mode when you can, so the insulting name might be counterproductive. I think most people who have used SQL have updated with an insufficiently restrictive where clause, or even forgotten to include the where clause entirely, at least once.

Make your models thin. Then make your models simple data structures.<p>Then your tests can build a data structure with just what is necessary for the test. Then your tests don&#x27;t need to be ordered.<p>The common problem is that models are fat, and to test them requires building up some very complex scenario. Every step mutates something. So the step order is critically important.<p>This is absolutely not necessary if your functions are pure. It&#x27;s also easier if your models are simple data structures, so they require less setup.<p>edit;added - if you make your models thin, then you need to add &quot;service&quot; modules which encapsulate the business logic. Taking it outside the models makes it more testable with less effort, and it also makes it less dependent on your framework.

We run ordered Integration Tests to save time as the set-up is onerous. Is that bad?

PNPM has an option called `shamefully-hoist` and it&#x27;s by far my favorite option of all time: <a href="https:&#x2F;&#x2F;pnpm.io&#x2F;npmrc#shamefully-hoist" rel="nofollow">https:&#x2F;&#x2F;pnpm.io&#x2F;npmrc#shamefully-hoist</a>

I disagree that ordered tests are bad. See, I don&#x27;t even have mutable state in my program -- but still have ordered tests for another reason: the ease of debugging. Say, if module A depends on module B, then B should be tested first, only then A, since if you test in the other direction, you might have a hard time figuring out whether A or B is misbehaving.

Is this still ok in today&#x27;s over-sensitive environment where &quot;blacklist&quot; files are taboo. (Btw, &quot;blacklist&quot; comes from British chimney cleaners).

Or use test_order :alpha

have fun testing a stateful system without order-dependent tests

Flagellants in tech are weird. You had to use a bad pattern once. You&#x27;ll be fine.

Related: Go finally added <i>support</i> for randomizing test order in 1.17! <a href="https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;go1.17" rel="nofollow">https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;go1.17</a> it&#x27;s disabled by default.<p>tl;dr: use `-shuffle on` so your tests don&#x27;t suck (as much)

no mames

How incredibly arrogant. 99% of the time that happens because the code sucks and the tests are impossible to write any other way without significant effort to mock resources and&#x2F;or just refactor the code (which of course breaks the old tests).<p>Anyone know if this is one of the many papercuts that probably killed off ruby (poor dev culture)? I never followed the language much.