[everyone]

The author is either crazy, or else maybe works in a very niche area where this makes sense. I work in games, and some modules are very conducive to automated testing.

Eg. complex math functions, it'd be very easy for them to be not quite right and you would never notice without tests, and also they will probably never change.

An area that would be stupid to test (with automated tests) for example, would be a UI menu.

* The test (ie. replicating a user pressing buttons via code) is probably gonna be more complex and less maintainable than the code its testing.

* If there is a bug it will be obvious in human acceptance testing.

* UI menus are gonna change drastically during development.

Anyway, I could see a misguided requirement for 100% code coverage massively hampering a project and potentially killing it.

[cbanek]

And yet, UI menus are one of the things that always break, and break right in front of the user ("I can't click this button. This is greyed out and it shouldn't be.") Menus should definitely be tested, and I think testing them in an automated way is fine. Without a working UI, you have no control.

You can even do model based testing.

For example, you're testing a word processor. You know that your state is no document. Then you click the open file button. Press some other buttons, and knowing what button it is, you should expect some change.

That being said, usually you can "press" the buttons virtually, for example sending window messages or calling the same functions as the buttons wire up to, rather than knowing the pixel layout.

People have been doing these things for years.

[everyone]

Your sort of reiterating my point.

I know UI stuff breaks a lot, but my point is that when it does break, its obvious. Bugs should be easily caught in human acceptance testing.

Also an automated test UI is never going to be the same as a human test, a lot of UI bugs can result from the vagaries of various physical devices touchscreens / gamepads / motion controls etc.

Also anything that tests such high level functionality is going to be very complicated and touch many parts of your code, it will probably be more complicated and less maintainable than the code its testing, which defeats the purpose imo, do you want to write tests for your tests?

UI stuff tends to change radically over development, so you'd be more than doubling your work with all the testcode youd have to write.

and it would still never replicate an actual human running the actual game, you absolutely are still going to be doing human acceptance tests + the closer you try and get automated tests to that the more complex and less maintainable they get.