Due Sunday, 21 March, midnight
Your software architect has decided that it is time to equip your dealer and your proto-player (the one with the silly strategy) with a graphical user display.
Task 1 Develop a method that allows a dealer to display (the essence of) its current configuration in a graphical window. Eventually, your software will use this method to provide a live view of complete games.
Also develop a method that allows an external player to display its current configuration in a graphical window. It must be possible to call the method during the game so that a programmer can observe how his/her automated (AI) player performs.
Delivery Create a sub-directory called gui and place all necessary files/modules into this sub-directory.
Task 2 Develop a single harness for running the display methods. The harness accepts a single JSON array from STDIN and writes nothing to STDOUT. The given array represent a (dealer) Configuration. The harness will open up two windows: one that displays the dealer’s configuration for the given input and another one that corresponds to the first player’s configuration.
./xgui < some-json-input > some-json-output
Note The title expresses the opposite sentiment of what this project is about. A course on software development cannot address the concerns of user experiences and interactivity, just as it cannot cover enough about software testing material. It is the basis for such courses, and I encourage you to check out those courses in your junior and senior years. At that point you will see that the title expresses a serious concern when it comes to real-world projects.
Do we have to develop unit tests for the GUIs?
No. You should have some json input files to make sure your GUIs can cope with the expected variety of configurations. But you cannot specify output files, so whatever you do, you don’t have tests. (Opening a window and eye-balling it is not testing.
Is it possible to develop testing harnesses for GUIs?
Yes, and for significant GUIs you absolutely must. DrRacket, for example, comes with a DrRacket-o-matic that (stress)tests the GUI in all kinds of ways. In additiion, GUIs need an HCI evaluation. Both of these are beyond the scope of the course.