Logical internal organization of integration tests for routes

Curious about how people organize their integration tests, specifically for routes, in terms of patterns for reuse by new devs.

I'm working on legacy tests and they follow 1 pattern properly, and none after that.

The one we do right is that we have specific ones per user type, which I've found to be recommendations by some people who care about this. This isn't going to change, so I'm just using it as meta data.

Inside the tests they're all over the place, depending on who wrote them.

Specifically I'm working with javaScript, which shouldn't matter too much, but it could also be important for some more experienced people.

Depending on who wrote it, when it was written, and if there were changes, the guts are a mess.

before is typically always at the top, usually followed by beforeEach. But some files have multiple before blocks, which make me throw up in my mouth, but refactoring this may not be worth the time (at this point).

after is mostly at the very bottom, but I can see a very valid argument for after be right after the before. In the cases after isn't at the bottom, it's not clear it was a deliberate placement, as in some cases there's stuff between the before and after, but never tests (thank Odin).

After all that, it descends into madness.

Sometimes there's a logical path on the tests, in a linear order of how things happen when hitting the route (check if params are set, validate thing, etc).

Other times the successful results are at the top, and then it's just like whoever wrote them added as they had time.

And then other times, it's whatever test was written last is either the first one, or the last one.

I'm a big fan of not letting new devs make decisions on things, so having a pattern to follow is a valuable tool. There's arguments to why this doesn't have value, but I don't want to be convinced of whether it has value, I am specifically interested in what other people do.

So a coffee break brainstorm, I came up with a few ideas, and I was curious what other people do.

Here are some ideas on patterns (covered or not):

1) Linear order of things.
pros: It leaves no room for confusion, tests occur in the order of operations. cons: technically it's only confirmable by scrolling through in order

2) Order by result codes. (so 400, 401, 404, 200, 204...etc) pros: super organized, a bit easier to search (how many 404s occur in code, is how many tests should be in 404 describe) cons: kind of doesn't solve the problem elegantly enough

3) Golden path on top, then something below pros: it's consistent....plus 200 tests will likely always be the longest cons: It's only slightly better than no pattern

I had other ideas that I just couldn't give a better pro than it's a bit consistent, so it's just barfing out bad ideas.

Any suggestions, advice, for or against any of these ideas would be appreciated. I'm certain I've completely overlooked other ideas.