Hacker News Reader

Comment by sublinear | Hacker News Reader

Oh boy. The fact that tests test arbitrary things should be enough for you to reconsider what you're saying. You can't possibly know if I'm "totally incorrect".

I'm not talking about sharing state between tests.

I'm talking about the code being tested having global state that is deeply entrenched in how it works, it's unreasonable to refactor, yet a test suite must be written.

What truly sucks is someone not even writing tests at all for the tangled parts which is extremely common to find because it breaks someone's precious mental model and they don't want to put their name on it.

View on HN

The way I see it, if your tests are dependent on mutable global state, they are bad. If they are not dependent on mutable global state, then other tests can't break your tests.

I'm not confident enough to say there aren't exceptions here though.

With mutable global state I wouldn't be too sure it's the tests that are the problem.

If your tests aren't accounting for the effects of mutable global state on the code under test they are bad tests. Randomization helps catch bad tests.

> The fact that tests test arbitrary things should be enough for you to reconsider what you're saying. You can't possibly know if I'm "totally incorrect".

You'll have to explain, then, the significant difference between:

  test_one:
    lots of setup code for scenario one
    assertions

  test_two:
    lots of setup code for scenario two
    assertions

where test_two only runs after test_one;

and:

  test_one:
    lots of setup code for scenario one
    assertions

  test_two:
    lots of setup code for scenario one
    lots of setup code for scenario two
    assertions

Of course, if the same "setup code for scenario one" running twice breaks things, then so would "running the suite twice", sure.

> I'm talking about the code being tested having global state that is deeply entrenched in how it works

"code being tested having global state that is deeply entrenched in how it works" does fall under "sharing state between tests".

Having code which relies on global state is probably the worst possible case, that's why I mentioned you can STILL write independent tests from each other. You could even run them in parallel, but you would have to use locks, but just by running them serially, you don't even need to do that. You just have to make sure that the global state has been reset after each test case properly.

If your project language is Python, pytest is providing all kinds of tools to setup and reset all kinds of global state (see the monkeypatch fixture). In other languages this can be solvable obviously, you might just need to write more helpers and might be more careful.

If you don't write your tests independent from each other, you will have an awful time debugging any failure and will waste insane working hours which could be prevented by a little bit of discipline.

> I'm talking about the code being tested having global state that is deeply entrenched in how it works

Could you give a specific/actual example of this? Technically a database is global state that is deeply entrenched in how an app works, but its trivial to make order independent tests that require certain records to exist.

I don't understand how this could be the case? If you need global state that carries over from another test and enforce it by order dependency, then the state is being shared. Otherwise, you can run the tests in any order.

Reply on news.ycombinator.com