I've some thoughts about our framework interview. Current interview is very
complex and hard to support. Below the summery of disadvantages of current
From user's point of view:
1. The remain questions is not visible until correct answer on current question.
2. The questions those open branches with additional questions is not notable
from others. It very easy to miss something.
From developer's point of view:
1. Exporting values to environment is very confusing. Some questions export
values by themselves, others don't export any values, and yet others export
values for a set of questions.
2. It's very hard and sometimes impossible to inject TCK specific questions to
the questions tree. Example: debugging group of questions. It's very desirable
to extend this group by TCK specific debugging questions (for example verbose
output of RPC calls for JAX-RPC TCK).
3. Very complex dependencies between questions. Any change in getNext() method
of any question should be made very carefully to avoid missing parts of interview.
So current interview need to be improved. See the ideas below.
There are three types of questions should be: key questions, extended
questions and simple questions.
Wizard-like questions - need to be answered to continue interview. These are
choice questions in general - user choose one of the branch - for example "Base
configuration" question or "Trusted/Untrusted" question.
Typical is yes/no question to hide/unhide specific branch of interview - for
example "Custom signer class". It should have behavior by default - typically
Questions for collecting information. Some simple questions can export their
values directly to the environment. In other cases key/extended questions should
export values related to their branch.
Not answered extended/simple questions should not block interview to be
continued. Simple question answer should be checked in the end of the interview
by clicking "Done" button (For this behavior may be JT Harness functionality
should be changed to provide more user-friendly ErrorQuestions).
The questions should be grouped by thematic (current interview is divided on
groups already). The each group should be possible to extend by TCK specific
The most of complication of getNext() method that very often logical group
has several last questions, each of them has getNext() method directed to the
first question of next logical group. The simple questions itself should not be
aware about next question, instead should be some class that know the sequence
of the questions in the logical group (we already have interface with such
functionality - PathResolver). The other complication that our questions have graph
dependencies but not tree dependencies. But several dependencies for one
question is rather rare case and can be encapsulated in the PathResolver.
Any feedback/comments on this proposition are highly appreciated. It would be
great if a result of discussion will be significant improvement of the framework