exercism
To develop a new exercise that features Delphi UI building capabilities
@kotp lets start a conversation about creating a new exercise that would feature Delphi's user interface design capabilities. In passing you've mentioned a calculator program. This sounds pretty do'able, assuming the calculator doesn't get too complicated (feature filled). There is an example project with DUnitX which touches on testing a UI. I'll leave it at that for now....
I am looking for the project that 'touches' on testing a UI with DUnitX and so far I have not been able to find it. :disappointed:
@kotp
I have not found an example project that utilizes the testing of a gui. But I have come across some examples of how to invoke a gui from a console app in order to make calls into the UI.
This is not a standard practice. Typically the UI and the underlying logic are only loosely coupled. The unit tests are typically geared towards the underlying logic. Test can be written to create an instance of a UI (though it will not be visible) and then simulate clicking on buttons etc. The results created by the simulated clicks can then be compared against the expected result to determine pass/fail of any given test.
The question I have: Should the exercise provide the UI (.dfm file) already built as a stub along with the the accompanying .pas file for the UI? I envision the stub file being devoid of events, which are called when objects on the UI are acted upon. The student would be required to write the events for the objects on the form along with the code necessary to complete the task. Likely the business logic would be contained in a separate unit or they could opt to write it within the stub unit.
Does this make sense?
I won't likely be available until Sunday to spend some time on this, but I think it is a worthwhile endeavor.
@kotp that's fine. I am not necessarily looking to schedule a time to work on this (yet), just wanting to do some brainstorming on the direction and nature this type of exercise should/could take.