Interesting work, the problem I see with using standard "unit tests" as fitness functions to evolve objects (or their functions) is that the resulting program may only compute the correct output for the defined test cases:
Say for example we want a function that adds two integers, we create a test with:
int x = 0; int y=0;
for (int x=0,y=0;x<10;x++,y++){
int result = sumIntegers(x,y);
assert (result== x+y);
writeFitness(x,y,(result-x-y)/(x+y));
}
A correct function (with fitness == 0) can be:
int sumIntegers(int x, int y) {
if (x == 1 and y == 1) return 2;
if (x == 2 and y == 2) return 4;
if (x == 3 and y == 3) return 6;
...
}
True, but that's true of most data mining and search algorithms. You are in danger of over-fitting the sample data. You can take steps to avoid this by giving more consideration to correct solutions that are shorter, in the hope that brevity avoids an exhaustive case statement.
I don't want to come off as if I disagree with you, the evolved programs will only be as good/complete as the unit tests they are evolved against.
Say for example we want a function that adds two integers, we create a test with:
A correct function (with fitness == 0) can be: Which is not semantically what we wanted.