Comment by noduerme

3 years ago

The manual testing really isn't very hard... where it relies on the same logic I use existing logic. Where it's new logic, particularly new UI, testing really can't be automated. Where it's not UI but server logic or DB queries, it's pretty explicit and tested six ways to Sunday before committing. I think the only true unit tests I ever wrote, if you can call them that, were to test pseudorandom behavior across distributions of things like character spawning in games, where player testing wouldn't be sufficient to spot anomalies. For something like that where you're going to have a billion variants, it makes sense to test for oddities on some subset of a million or two. In other words, tests to make sure that output fit a certain curve. Not that logic itself worked or didn't work, because if I can think of a test to write where it might fail, I'd already have fixed it not to fail under that test.

2 comments

noduerme

blowski 3 years ago

There is a difference between these three statements:

1. It can't be tested.

2. I don't know how to test it.

3. The tests don't give enough value given the effort required to write them.

The less experience you have with tests, the worse the cost-benefit analysis comes out. This is why people disagree over unit tests. Good tests give a huge productivity gain, but the opposite is true of bad tests. Unfortunately, there's a vicious cycle:

  You write bad tests 
  -> You don't value tests 
  -> You don't spend time learning to improve tests 
  -> You continue to write bad tests

hbrn 3 years ago

The problem is that writing good tests is harder than writing original code.
And what happens in most companies? We hired a junior engineer and don't have work for them... let them write tests!