> Unless you have a ten-line† program or one hell of a suite of unit tests documenting every single interaction with the world your system ever performs‡, you can never be sure that a first-day employee 'fixing' a bug hasn't introduced a new obscure one somewhere.
New employee creates test to cover bug.
Fixes bug.
Runs test suite. Test suite passes.
Commits code.
All under the watchful eye of another developer.
You keep pushing specific work environments into different situations. Not all tests work for all cases. Stop assuming this. Your entire argument against this strategy is that X doesn't work in Y. You ignore that X works with X.
> Do you deny that this test is trivial to game for those who want to game it?
Yes, if you want to work for a company that does something you don't like, it's easy to game.
> Or do you claim that just passing this test, at whatever motivation, is a useful signal?
If you choose to do the task rather than just game it, it helps in several specific ways. Taking the code committing part, it ensures you have everything set up correct, from development environment, testing suite, VM, connections to dev, intergrated, staging and live, etc. You have your editor setup, connections to source control, understand the ticketing system.
Their is a lot of value knowing that everything is setup. There is also a lot of value with the person knowing they just deployed code.
> other than not being philosophically opposed to meaningless tests?
Just because you assume something is meaningless doesn't mean it is.
> About which part?
About the strategy being useful or not. You think the strategy is useless. I believe it's not, and has proven it's value.
That being said, the only thing you've done is construct hypothetical worst case scenarios and question how it's good, which is next to worthless.
If you have honest questions about the strategy, go ahead and ask. If you just want to play more games with hypothetical situations, let's just end the discussion here.
>> other than not being philosophically opposed to meaningless tests?
> Just because you assume something is meaningless doesn't mean it is.
For the record, I meant philosophically opposed to tests the tested believes to be meaningless - which is the only useful definition.
Your explanations push the hypothetical case far, far away from the test presented initially. It sounds less like the equivalent of cleaning bathrooms and more like actual work. I will end the discussion now.
> For the record, I meant philosophically opposed to tests the tested believes to be meaningless - which is the only useful definition.
Then, for the record, in this case, it helps to highlight people who think they know it all when they really don't.
> Your explanations push the hypothetical case far, far away from the test presented initially. It sounds less like the equivalent of cleaning bathrooms and more like actual work.
Again, confusing execution and strategy.
But then again, you're philosophically opposed to tests the you believe are meaningless.
New employee creates test to cover bug. Fixes bug. Runs test suite. Test suite passes. Commits code. All under the watchful eye of another developer.
You keep pushing specific work environments into different situations. Not all tests work for all cases. Stop assuming this. Your entire argument against this strategy is that X doesn't work in Y. You ignore that X works with X.
> Do you deny that this test is trivial to game for those who want to game it?
Yes, if you want to work for a company that does something you don't like, it's easy to game.
> Or do you claim that just passing this test, at whatever motivation, is a useful signal?
If you choose to do the task rather than just game it, it helps in several specific ways. Taking the code committing part, it ensures you have everything set up correct, from development environment, testing suite, VM, connections to dev, intergrated, staging and live, etc. You have your editor setup, connections to source control, understand the ticketing system.
Their is a lot of value knowing that everything is setup. There is also a lot of value with the person knowing they just deployed code.
> other than not being philosophically opposed to meaningless tests?
Just because you assume something is meaningless doesn't mean it is.
> About which part?
About the strategy being useful or not. You think the strategy is useless. I believe it's not, and has proven it's value.
That being said, the only thing you've done is construct hypothetical worst case scenarios and question how it's good, which is next to worthless.
If you have honest questions about the strategy, go ahead and ask. If you just want to play more games with hypothetical situations, let's just end the discussion here.