So if behavioral tests were a part of the fitness function in a genetic programming environment, we could probably find a whole new *dimension* of test methodology if we started with "mutation testing."
If you aren't familiar with mutation testing, I recommend googling on it; it's the best thing I've found to deal with the infinite regress (is that the right term?) that one finds when asking the question, "...but who tests the tests?" That, and it's sort of ...really fun:) I think that there might be a whole world of possibilities around using mutation to test the tests if the tests were in the fitness function. Problems we regularly have in industry: the customer isn't totally clear on what the requirements are. The customer hasn't fleshed out all of the requirements. There's a trend (maybe a fad, who knows) around encoding requirements as tests. Mutation testing (as it is today) is really just a brilliant, quick hack. I don't think we've seen the bounds of it yet. People are mostly doing it at the source code level (that I know of) but one interesting step might be to try applying a similar tactic at the level of the abstract syntax tree. With a common intermediate representation, this could be universally applicable to a pile of languages implemented using e.g. Ometa. What if we could use genetic programming to improve programmatically formalized requirements / tests? Someone else on the list has already suggested this, and it feels right somehow. It also feels deeply meta. FWIW, thanks for engaging with the crazy ideas, the last few days. I hope I haven't bored too many people here with them:) _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
