| A challenge with targets is gaming metrics which isn't great My gut is that we are in this dark age of the field where we are stuck between low hanging fruit and doing this exceptionally well. I'm not sure how we achieve balance, but I do ponder it. For example, in the domain of building a small game, then coverage is not really needed as the quality is measured more by playing the game. In the domain of infrastructure where I have toiled for over a deacde, I have come to expect amazing coverage since so many CoE/SEV/prod issues have "did we have a test for that?". I've worked with teams getting not just 100% but all sorts of E2E and other stuff to test software. A key problem is that what is good in one domain is awful for another, and we can't speak in general metrics as a good rule. Is 70% good? Well, maybe... Maybe not... As I reflect on simple games, I am working on a way to automatically build unit tests for a class of games I care about: board games. As I look into how to do AI for arbitrary games (I have a random player model for giggles at the moment), I find that I could use a bit of AI to build a minimal spanning set of cases which exercise all the code paths in different combinations. This is possible because my language tightly couples state and compute ( http://www.adama-lang.org/ ), but I believe this provides an interesting clue out of this mess. As we look into AI to write code, why don't we start with using AI to find how to automate testing and then bring a human in the loop to be like "Yo, is this the right behavior?" and then go from there. |