- iTutor accepts three classes as inputs: Teacher solution, Student solution, and an interface common to them. The users of iTutor can be relieved by removing the interface as input. This interface can automatically be inferred from the public methods of Teacher solution. Also, before processing these solutions, iTutor needs to check whether it can find equivalent public methods in the student solution, if not, it can flag error.
- iTutor currently renames the solutions to Student and Teacher. This can be easy if there is a single class. But situation can be difficult if there are many classes. Bellanov needs to investigate and develop features to address this issue.
- Currently, the length of method-call sequences in tests has been limited to three. This can be made configurable.
- Add "assertions" to all case statements, this would help in automatically generating test cases with variable number of sequences (as assertions exist right after the method-call invocations)
- Make the index used in the switch statement as symbolic and remove it as a parameter for the driver method
- Remove arguments passed to method calls as parameters from the driver method.
- When the methods under test accept non-primitive types, a deep copy of the argument should be made. If not, the method under test of teacher solution may modify the argument before passing it to student solution. Similar techniques need to developed for comparing non-primitive return types.
- A problem arises where methods can be overloaded, leading to multiple possibilities when instantiating each solution. iTutor shall generate numerous test drivers, each of which focuses on one constructor.
- The logging feature that currently uses print line statements shall be implemented to send that information to a file, which can be accessed and analyzed later.
Monday, November 2, 2009
The feedback compiled from the iTutor demo is as follows: