Final-TurnIn

Final Code Turn-In for Racket-QA.

WebPage v0.4.0

Racket-Doc has been improved to display code bodies in a cleaner format than before.

WebPage

New release for the web page. The application is now one main GUI.

Milestone2

README files are provided in the zipped archives as well, but here are quick links for this version of Racket-QA.

Running and Testing this Version of Racket-QA

• Bottle-Racket and Test-Capture
• QA-Email
• Scheduler
• Racket-Doc

Second Milestones

1. The file test-tracker.rkt has been formatted with the specifications of Racket-Doc and is able to be converted successfully and displayed into a web page. In the future, bn-to-racket.rkt is something that we'd like to convert properly.
2. Racket-Doc is able to successfully port extracted data to the web pages, but with several stringent limitations. See the Racket-Doc README for more details. Before the final code turn-in, Racket-Doc is planned to be more flexible in its conversions.
3. Test-Capture can run a test suite file upon the user's choice, regardless if it's a test suite file generated from Bottle-Racket as long as it maintains consistent structure of a test suite file.
   1. The test suite midterm has been provided for this purpose.
4. Scheduler meets the expectations for the second milestone.
   1. Scheduler has been tested fully functional with ability to execute both Bottlenose test suite files and other RackUnit test suite files on Windows, Linux, and Mac at any specified time.
   2. Scheduler has successfully generated result files for test run-ups as well as sent them to a mailing list configured through its UI.
   3. Scheduler is only functional when loaded in Dr.Racket framework. Once Dr.Racket closes, time-tracking threads are killed, and scheduled tests will not run anymore.

Future Tasks

1. We can standardize our file headers. Currently:
   1. Roy uses ;; *** style headers
   2. James uses ;;
   3. Yong uses #|| style headers
   4. We have also been putting varying information on our headers. Commenting needs to be standardized so style differences don't separate the project.
2. We need to ensure our code is compatible across major platforms - Windows, Linux, and Mac. We have four different components that have been developed in all different platforms:
   1. Windows for Bottle-Racket
   2. Linux for Racket-Doc
   3. Mac and Windows for Test Scheduler and QA-Email
   4. Although Racket language is supposed to be cross-platform, it is not guaranteed that a code written in one platform would work correctly in another. It wouldn't make sense for a part of a program to work on one platform, and another part to be on a different platform when they are all in one program. We need to test compatibility as a whole program to ensure parts of it doesn't break on users.
3. If we have time, we can create a user interface that brings together all components of the Racket-QA application.
   1. Currently, we have three major components (except QA-Email which is a helper to other components) that have been developed separately and operates independently from each other. From the user's perspective, it would make more sense for an application to have one executable, instead of three. Maybe we can have a small start-up UI with 3 icon buttons launching each component.

Milestone1

README files are provided in the zipped archives as well, but here are quick links for this version of Racket-QA.

Running and Testing this Version

• Bottle-Racket and Test-Capture
• QA-Email
• Racket-Doc

We were able to meet all of our First Milestones:

1. Bottle-Racket is able to convert Problem Sets 1, 2, 3, and 5 with the following changes in mind:
   1. ps3a's print test will be changed to not do a print.
   2. ps5b's test file was to be modified since the procedures in 2.57 and 2.58 have the same name, resulting in duplicate definitions.
2. Test-Capture is able to do three things now:
   1. Generate test-running scripts for a properly formatted test area
   2. Configure a mailing list to send test results to, using the QA-Email API
   3. Run the generated test-running scripts and send the test results to the specified mailing list
3. Racket-Doc currently is able to do the following:
   1. Extract user-specified attributes from .rkt files, and save them to file.
   2. Creates fully navigable web pages on a local host, with hard-coded data.
4. QA-Email currently has the following complete:
   1. A UI and file database for managing and storing mailing lists is functional.
   2. Is able to send a test email to see if the mailing list is sending out emails to the right people.
   3. Is able to send a test results text file to a mailing list. Test-Capture uses this API.

Concerning the Second Milestones and what is still being worked on:

1. Bottle-Racket and Test-Capture's code will be formatted with Racket-Doc's specifications. Racket-Doc will be tested to see if it displays properly formatted source code from this project component.
2. An example test suite and area file will be provided that is not a bottlenose case. It will still be properly formatted, but will show we aren't limited to just Bottlenose tests.
3. Racket-Doc will be able successfully port the extracted data to the web pages. Right now the web pages contain hard-coded data. Also, It will use user-specified files (currently it reads from "Test.rkt" and writes to "OutputDoc.rkt), and will support Linux, OSX, and Windows (currently tested on Linux only).
4. Scheduler will be created and tested with capability to send emails automatically after the scheduled test run-up.