From 5ff7ea4cbf5efdde5c84bca619b6b1fdbb5b5174 Mon Sep 17 00:00:00 2001 From: Roy Van Liew Date: Sun, 5 Apr 2015 14:36:19 -0400 Subject: [PATCH 1/9] First draft of README, needs more revising --- README.md | 71 ++++++++++++++++++++++++++++++------------------------- 1 file changed, 39 insertions(+), 32 deletions(-) diff --git a/README.md b/README.md index 5335908..6b277b2 100644 --- a/README.md +++ b/README.md @@ -14,6 +14,8 @@ The proposal should be no longer than necessary, but long enough to include crit Remember, you can do some neat [formatting things with Markdown.][markdown] + + ## In-Class Presentation Instructions Teams will each deliver an in-class presentation. **Presentations will be Wednesday, April 8** (and Friday, April 10 as necessary). The presentation material is due on April 8 by 9 am for everybody. [See piazza for full schedule.][piazza] @@ -21,57 +23,62 @@ Your team will have two minutes to present. Create presentation with two or thre (Template follows. You may delete this line and all above it. Please edit the following template to create your report.) -# Project Title: title here (10 words maximum) +# Project Title: Racket-QA ### Problem Statement -Describe your problem, and why it is interesting. - -### Problem Analysis -Explain what approaches from class you will bring to bear on the problem. Be explicit and succinct. -### Data set or other source materials -If you will be working with existing data, where will you get those data from? (Dowload it from a website? access it in a database? create it in a simulation you will build....) +* Racket has a unit testing library RackUnit which can run test cases and test suites, but it seems incomplete as an API from a QA Engineer standpoint and its documentation is poor. We want to create some well-documented user-friendly utilities that a QA Engineer could use in Racket. +* Someone can use RackUnit to run tests, but can't send those results out to a QA team and can't schedule when the tests should be run. +* Along with encouraging test-driven development, there should also be standards established for documentation. Racket-Doc is a component of this project which displays styled text in web pages. +* The above three points are the big picture focus, but in our case we are using bottlenose test cases from this course as the basis of individual test suites to run. The problem with the current Perl test cases is that if people want to test their code on the assignments, they have to test one case at a time manually which is tedious and inefficient. Using RackUnit, all test cases can run at once and the person sees exactly which cases failed and why; running the Perl test cases just say "not ok" which isn't helpful, and those scripts take a while to run. -How will you convert that data into a form usable for your project? -Do your homework here: if you are pulling data from somewhere, actually go download it and look at it. Explain in some detail what your plan is for accomplishing the necessary processing. +### Problem Analysis -If you are using some other starting materails, explain what they are. Basically: anything you plan to use that isn't code. +* Use Higher-Order-Procedures discussed in class. These include procedures such as map, filter, zip, and keeping the substitution model in mind when creating new data from original data through these procedures. +* More could be entered here -### Deliverable and Demonstration -Explain exactly what you'll have at the end. What will it be able to do at the live demo? +### Data set or other source materials -What exactly will you produce at the end of the project? A piece of software, yes, but what will it do? Here are some questions to think about (and answer depending on your application). +* For the most part the scripts will be working with existing data from files stored on the computer. This is especially true for Bottle-Racket. +* Bottle-Racket takes a source Racket assignment file and a Bottlenose Perl test file from the computer as data. The lines from these files are read as strings, and HOP are used to work with the data as lists of strings. New files will be generated such as the test suite and test area file. +* Test-Capture is a utility that will take the test area files generated from Bottle-Racket to create test-running scripts that save test results to file and can be sent out to a team via email. +* Racket-Doc, James needs to give input on how the data will be retrieved etc. +* QA-Email, will get email body from test results file generated by a test-running script that's used after Bottle-Racket creates a test area file. Yong Cho can give input on how Address Book and Scheduler will work with what kinds of data (e.g. are the Address Book files just simple text files where each line is an email address?) -Will it run on some data, like batch mode? Will you present some analytical results of the processing? How can it be re-run on different source data? +### Deliverable and Demonstration -Will it be interactive? Can you show it working? This project involves a live demo, so interactivity is good. +* Be able to take a bottlenose assignment file, convert it into a test suite, and then make a test-running script for that suite. +* Then running that script will produce a file containing the test results for that suite, and email the contents of that file out to a QA team. +* Racket-Doc will be able to look through properly formatted Racket code and display it nicely in a web browser (James needs to elaborate on this one) +* Scheduler will be able to take a test-running script generated from Test-Capture and run that script in certain time period intervals. +* Address Book will be able to change where emails go for test results. ### Evaluation of Results -How will you know if you are successful? -If you include some kind of _quantitative analysis,_ that would be fantastic. -## Work Plan and Schedule -Explain how you will go from proposal to finished product. Write your general plan here. -There are three deliverable milestones to explicitly define, below. The nature of deliverables depend on your project, but may include things like processed data ready for import, core algorithms implemented, interface design prototyped, etc. +- Bottle-Racket will be able to convert a variety of the assignment Perl test case files. +- Scheduler will be able to successfully run test-running scripts in consistent intervals, even when address books are changed (files containing email address of a team) and when source code is changed. +- Racket-Doc, need James's input on this -You will be expected to turn in code, documentation, and data (as appropriate) at each of these stages, so take care in writing concrete steps for your schedule. +## Work Plan and Schedule -In this general plan, and in the deliverables below. +An excel spreadsheet representing a calendar will be used as a planner. -### First Milestone (04-13) -What exactly will be turned in on this day? +First Milestone (04-13) +* Bottle-Racket will be able to convert the first 3 assignments along with freds-db (that one requires loading in definitions from another file). +* Test results can be sent out to the QA Email group by reading in the test result files generated from the test-running scripts created by Test-Capture. +* Racket-Doc, need James's input on this +* Very simple Address Book implementation? (vague -- needs more detail) +* Scheduler can load in a test-running script and send an email out to QA team, maybe since for the first milestone the QA team could be hardcoded if a simple address book isn't accomplished yet? More complex time operations could be done in the second milestone maybe. -### Second Milestone (04-21) -What exactly will be turned in on this day? +Second Milestone (04-21) +* Improve Address Book (vague -- needs more detail) +* Scheduler can be configured for different time intervals and if an email will be sent or not. ## Group Responsibilities -Here each group member gets a section where they, as an individual, detail what they are responsible for in this project. Each group member writes their own Responsibility section. Include the milestones and final deliverable. - -### Susan Scheme -will write the.... -### Leonard Lambda -will work on... +* Roy will work on Bottle-Racket and Test-Capture. Testing of other team members' code to see their progress, and have some involvement with Address Book and Scheduler. +* Yong will work on QA-Email (this includes Address Book) and Scheduler. +* James will work on Racket-Doc ## Proposal Presentation Link insert your google presentation public link here, so with one click it will open up in the browser and you can present. From fc5b88bbfdcd2c236e69bcbc0c5dfbef8d50472a Mon Sep 17 00:00:00 2001 From: YongCho Date: Sun, 5 Apr 2015 17:05:27 -0400 Subject: [PATCH 2/9] Update README.md --- README.md | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 6b277b2..71a0ae6 100644 --- a/README.md +++ b/README.md @@ -47,16 +47,20 @@ Your team will have two minutes to present. Create presentation with two or thre ### Deliverable and Demonstration -* Be able to take a bottlenose assignment file, convert it into a test suite, and then make a test-running script for that suite. -* Then running that script will produce a file containing the test results for that suite, and email the contents of that file out to a QA team. +* The program will be able to take a bottlenose assignment file, convert it into a test suite, and then make a test-running script for that suite. +* In addition to Bottlenose tests, the program is capable of running any RackUnit test provided by the user. +* The program will present to the user a GUI showing the test result, as well as a file containing the results for the test suite. +* The program will provide an interface to schedule a test to be run automatically with specified test-running script. This feature is targeted mainly for regression testing of a project involving multiple developers. +* The program will present an interface to configure an email database associated with each test, which will be used to send out a scheduled test result upon the user's request. * Racket-Doc will be able to look through properly formatted Racket code and display it nicely in a web browser (James needs to elaborate on this one) -* Scheduler will be able to take a test-running script generated from Test-Capture and run that script in certain time period intervals. -* Address Book will be able to change where emails go for test results. ### Evaluation of Results - Bottle-Racket will be able to convert a variety of the assignment Perl test case files. -- Scheduler will be able to successfully run test-running scripts in consistent intervals, even when address books are changed (files containing email address of a team) and when source code is changed. +- Scheduler will be able to successfully run test-running scripts in consistent intervals, even when mailing list associated with the test is updated between consecutive test run-ups and when the source code tested is changed. +- Email module will be able to detect when a user enters an incorrect email address or when a database stored in the user's storage is currupted between the program run-ups, and notify the user of the invalid entries. + + - Racket-Doc, need James's input on this ## Work Plan and Schedule @@ -67,17 +71,17 @@ First Milestone (04-13) * Bottle-Racket will be able to convert the first 3 assignments along with freds-db (that one requires loading in definitions from another file). * Test results can be sent out to the QA Email group by reading in the test result files generated from the test-running scripts created by Test-Capture. * Racket-Doc, need James's input on this -* Very simple Address Book implementation? (vague -- needs more detail) -* Scheduler can load in a test-running script and send an email out to QA team, maybe since for the first milestone the QA team could be hardcoded if a simple address book isn't accomplished yet? More complex time operations could be done in the second milestone maybe. +* User interface and file database for managing and storing mailing lists, as well as sending emails with a test result will be fully functional. Second Milestone (04-21) -* Improve Address Book (vague -- needs more detail) -* Scheduler can be configured for different time intervals and if an email will be sent or not. +* The program will be able to run both Bottlenose test and other RackUnit test upon users' choice. +* User interface for selecting between a Bottlenose test and other Racket test will be available. +* Test scheduler will be created and tested with capability to send emails automatically after the scheduled test run-up. ## Group Responsibilities * Roy will work on Bottle-Racket and Test-Capture. Testing of other team members' code to see their progress, and have some involvement with Address Book and Scheduler. -* Yong will work on QA-Email (this includes Address Book) and Scheduler. +* Yong will work on test scheduler and email components, and possibly creating a UI for configuring and executing non-Bottlenose tests (it is not clear at this point whether a separate UI will be needed for non-Bottlenose tests). * James will work on Racket-Doc ## Proposal Presentation Link From 3a0eead1fe4f5cd8eef7340350f35752a8cd4380 Mon Sep 17 00:00:00 2001 From: Roy Van Liew Date: Sun, 5 Apr 2015 19:41:02 -0400 Subject: [PATCH 3/9] Clarified some things about the test areas, bottlenose suites are just one example of a suite that's created and the test areas just need to be properly formatted with the test list specified in the suite --- README.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 71a0ae6..ab84820 100644 --- a/README.md +++ b/README.md @@ -47,25 +47,25 @@ Your team will have two minutes to present. Create presentation with two or thre ### Deliverable and Demonstration -* The program will be able to take a bottlenose assignment file, convert it into a test suite, and then make a test-running script for that suite. -* In addition to Bottlenose tests, the program is capable of running any RackUnit test provided by the user. -* The program will present to the user a GUI showing the test result, as well as a file containing the results for the test suite. -* The program will provide an interface to schedule a test to be run automatically with specified test-running script. This feature is targeted mainly for regression testing of a project involving multiple developers. -* The program will present an interface to configure an email database associated with each test, which will be used to send out a scheduled test result upon the user's request. +* The program `Bottle-Racket` is a GUI that will be able to take a bottlenose assignment file and convert it into a test suite file that is also specified in a generated test area file. Then `Test-Capture` is a GUI used to make a test-running script for that test area file which specifies the test suite to run. +* In addition to Bottlenose tests, the project will be capable of running a properly formatted RackUnit test area with a test suite provided by the user. +* The project will provide a file containing the results for the test area, and this file can be sent as an email to the development team. +* The project will provide `Scheduler`, a GUI to schedule a test area to be run automatically with a specified test-running script. This feature is targeted mainly for regression testing of a project involving multiple developers. +* The project will provide `QA-Email`, a GUI to configure an email database associated with each test area, which will be used to send out a scheduled test result upon the user's request. * Racket-Doc will be able to look through properly formatted Racket code and display it nicely in a web browser (James needs to elaborate on this one) ### Evaluation of Results - Bottle-Racket will be able to convert a variety of the assignment Perl test case files. -- Scheduler will be able to successfully run test-running scripts in consistent intervals, even when mailing list associated with the test is updated between consecutive test run-ups and when the source code tested is changed. -- Email module will be able to detect when a user enters an incorrect email address or when a database stored in the user's storage is currupted between the program run-ups, and notify the user of the invalid entries. - - +- Scheduler will be able to successfully run test-running scripts in consistent intervals, even when the mailing list associated with the test area is updated between consecutive test run-ups and when the source code tested is changed. +- Email module will be able to detect when a user enters an incorrect email address or when a database stored in the user's storage is corrupted between the program run-ups, and notify the user of the invalid entries. - Racket-Doc, need James's input on this ## Work Plan and Schedule -An excel spreadsheet representing a calendar will be used as a planner. +An excel spreadsheet representing a calendar will be used as a planner. Some things to consider: +* Scheduler will be implemented in the Second Milestone. +* The user doesn't need to specify if the test area loads in a Bottlenose test suite. We already assume the QA Engineer knows how to create test suites and test areas, we are just using Bottlenose tests as the suites. The key is to have properly formatted test area files, and any kind of suite can be run. First Milestone (04-13) * Bottle-Racket will be able to convert the first 3 assignments along with freds-db (that one requires loading in definitions from another file). @@ -74,15 +74,16 @@ First Milestone (04-13) * User interface and file database for managing and storing mailing lists, as well as sending emails with a test result will be fully functional. Second Milestone (04-21) +* Racket-Doc, maybe some additional features or was only partially complete in First Milestone? * The program will be able to run both Bottlenose test and other RackUnit test upon users' choice. * User interface for selecting between a Bottlenose test and other Racket test will be available. * Test scheduler will be created and tested with capability to send emails automatically after the scheduled test run-up. ## Group Responsibilities -* Roy will work on Bottle-Racket and Test-Capture. Testing of other team members' code to see their progress, and have some involvement with Address Book and Scheduler. -* Yong will work on test scheduler and email components, and possibly creating a UI for configuring and executing non-Bottlenose tests (it is not clear at this point whether a separate UI will be needed for non-Bottlenose tests). -* James will work on Racket-Doc +* Roy will work on `Bottle-Racket` and `Test-Capture`. Testing of other team members' code to see their progress, and have some involvement with Address Book and Scheduler. +* Yong will work on test scheduler `Scheduler`, and email component `QA-Email`. +* James will work on Racket-Doc. ## Proposal Presentation Link insert your google presentation public link here, so with one click it will open up in the browser and you can present. From 6aae8dfc6da8faaba35b5b94de8a55afc415e68a Mon Sep 17 00:00:00 2001 From: Roy Van Liew Date: Mon, 6 Apr 2015 22:22:55 -0400 Subject: [PATCH 4/9] Almost done with the readme --- README.md | 61 ++++++++++++++++--------------------------------------- 1 file changed, 18 insertions(+), 43 deletions(-) diff --git a/README.md b/README.md index ab84820..fa319a2 100644 --- a/README.md +++ b/README.md @@ -1,49 +1,26 @@ # FP4-proposal Project Proposal is due 2015-04-08 at 8am -Produce a plan for your final project, and prepare an in-class presentation. - -Ask questions, as always, [on piazza!][piazza] - -## Written Proposal Instructions - -Teams will submit ONE written proposal, with sections that each member has done individually detailing their proposed contributions. The submission will be on github, as a pull request of this very file. Below is a template proposal report. - -You should be proposing something that you have high confidence that you can achieve, and the proposal should project that confidence. -The proposal should be no longer than necessary, but long enough to include critical detail. Three pages is appropriate. Diagrams are welcome. - -Remember, you can do some neat [formatting things with Markdown.][markdown] - - - -## In-Class Presentation Instructions -Teams will each deliver an in-class presentation. **Presentations will be Wednesday, April 8** (and Friday, April 10 as necessary). The presentation material is due on April 8 by 9 am for everybody. [See piazza for full schedule.][piazza] - -Your team will have two minutes to present. Create presentation with two or three slides. Make the slides in google drive, and share the public-viewable link at the bottom of this report. The day of presentations, I'll have the list of links on the display computer, so each team can simply click their link and begin. - -(Template follows. You may delete this line and all above it. Please edit the following template to create your report.) - # Project Title: Racket-QA ### Problem Statement * Racket has a unit testing library RackUnit which can run test cases and test suites, but it seems incomplete as an API from a QA Engineer standpoint and its documentation is poor. We want to create some well-documented user-friendly utilities that a QA Engineer could use in Racket. * Someone can use RackUnit to run tests, but can't send those results out to a QA team and can't schedule when the tests should be run. -* Along with encouraging test-driven development, there should also be standards established for documentation. Racket-Doc is a component of this project which displays styled text in web pages. +* Along with encouraging test-driven development, there should also be standards established for documentation. Racket-Doc is a component of this project which uses an interactive GUI to extract documentation and user-specified attributes from `.rkt` source files, and save this to file for future preview as well as display it as styled text in web pages. * The above three points are the big picture focus, but in our case we are using bottlenose test cases from this course as the basis of individual test suites to run. The problem with the current Perl test cases is that if people want to test their code on the assignments, they have to test one case at a time manually which is tedious and inefficient. Using RackUnit, all test cases can run at once and the person sees exactly which cases failed and why; running the Perl test cases just say "not ok" which isn't helpful, and those scripts take a while to run. - ### Problem Analysis -* Use Higher-Order-Procedures discussed in class. These include procedures such as map, filter, zip, and keeping the substitution model in mind when creating new data from original data through these procedures. -* More could be entered here +* Higher-Order-Procedures discussed in class such as map, filter, zip will be used. We also need to keep the substitution model in mind when creating new data from original data. +* As a team we need to consider what level of abstraction to implement for our project. ### Data set or other source materials * For the most part the scripts will be working with existing data from files stored on the computer. This is especially true for Bottle-Racket. -* Bottle-Racket takes a source Racket assignment file and a Bottlenose Perl test file from the computer as data. The lines from these files are read as strings, and HOP are used to work with the data as lists of strings. New files will be generated such as the test suite and test area file. -* Test-Capture is a utility that will take the test area files generated from Bottle-Racket to create test-running scripts that save test results to file and can be sent out to a team via email. -* Racket-Doc, James needs to give input on how the data will be retrieved etc. -* QA-Email, will get email body from test results file generated by a test-running script that's used after Bottle-Racket creates a test area file. Yong Cho can give input on how Address Book and Scheduler will work with what kinds of data (e.g. are the Address Book files just simple text files where each line is an email address?) +* `Bottle-Racket` takes a source Racket assignment file and a Bottlenose Perl test file from the computer as data. The lines from these files are read as strings, and HOP are used to work with the data as lists of strings. New files will be generated such as the test suite and test area file. +* `Test-Capture` is a utility that will take the test area files generated from Bottle-Racket to create test-running scripts that save test results to file and can be sent out to a team via email. +* `Racket-Doc` recieves a .rkt file, or a directory containing .rkt source files. These must be provided by the user (although example test files will be provided). Also, the resulting documentation is displayed in a web page, so a web browser must be installed (for testing purposes we are using Firefox). +* `QA-Email` will get the email body from the test results file generated by a test-running script that's used after `Bottle-Racket` creates a test area file. ### Deliverable and Demonstration @@ -52,14 +29,14 @@ Your team will have two minutes to present. Create presentation with two or thre * The project will provide a file containing the results for the test area, and this file can be sent as an email to the development team. * The project will provide `Scheduler`, a GUI to schedule a test area to be run automatically with a specified test-running script. This feature is targeted mainly for regression testing of a project involving multiple developers. * The project will provide `QA-Email`, a GUI to configure an email database associated with each test area, which will be used to send out a scheduled test result upon the user's request. -* Racket-Doc will be able to look through properly formatted Racket code and display it nicely in a web browser (James needs to elaborate on this one) +* `Racket-Doc` will be be able to extract "requires", "provides", data, procedure headers, and documentation (specified by the form `#|...documentation here...|#`) from files containing the `.rkt` file extension. This well be user-specified with a GUI. The user will be able to specify exactly which features should be extracted. It will then allow the user to either save this data to a file, or display it in web pages. ### Evaluation of Results -- Bottle-Racket will be able to convert a variety of the assignment Perl test case files. -- Scheduler will be able to successfully run test-running scripts in consistent intervals, even when the mailing list associated with the test area is updated between consecutive test run-ups and when the source code tested is changed. -- Email module will be able to detect when a user enters an incorrect email address or when a database stored in the user's storage is corrupted between the program run-ups, and notify the user of the invalid entries. -- Racket-Doc, need James's input on this +* Bottle-Racket will be able to convert the first 4 assignment test files. +* Scheduler will be able to successfully run test-running scripts in consistent intervals, even when the mailing list associated with the test area is updated between consecutive test run-ups and when the source code tested is changed. +* Email module will be able to detect when a user enters an incorrect email address or when a database stored in the user's storage is corrupted between the program run-ups, and notify the user of the invalid entries. +* Racket-Doc will be able to successfully extract the user-specified attributes, save it to file, and display it in web pages running on the local host. ## Work Plan and Schedule @@ -70,24 +47,22 @@ An excel spreadsheet representing a calendar will be used as a planner. Some thi First Milestone (04-13) * Bottle-Racket will be able to convert the first 3 assignments along with freds-db (that one requires loading in definitions from another file). * Test results can be sent out to the QA Email group by reading in the test result files generated from the test-running scripts created by Test-Capture. -* Racket-Doc, need James's input on this +* Racket-Doc will be able to extract user-specified attributes from .rkt files, and save them to file. The web pages should be fully navigable (on a local host), although they will contain hard-coded data. * User interface and file database for managing and storing mailing lists, as well as sending emails with a test result will be fully functional. Second Milestone (04-21) -* Racket-Doc, maybe some additional features or was only partially complete in First Milestone? -* The program will be able to run both Bottlenose test and other RackUnit test upon users' choice. -* User interface for selecting between a Bottlenose test and other Racket test will be available. +* Racket-Doc will be able successfully port the extracted data to the web pages. +* The project will be able to run a Bottlenose test or other RackUnit test upon users' choice. * Test scheduler will be created and tested with capability to send emails automatically after the scheduled test run-up. ## Group Responsibilities * Roy will work on `Bottle-Racket` and `Test-Capture`. Testing of other team members' code to see their progress, and have some involvement with Address Book and Scheduler. * Yong will work on test scheduler `Scheduler`, and email component `QA-Email`. -* James will work on Racket-Doc. +* James will work on `Racket-Doc`. ## Proposal Presentation Link -insert your google presentation public link here, so with one click it will open up in the browser and you can present. +[**Racket-QA PowerPoint**][powerpoint] -[piazza]: https://piazza.com/class/i55is8xqqwhmr?cid=453 -[markdown]: https://help.github.com/articles/markdown-basics/ +[powerpoint]: https://docs.google.com/presentation/d/1Ff5LjW92cEDqhPJGla6IjBosKEh1DuKNqqaBsNtIqRg/edit?usp=sharing From 3135f7e82bfeb92543762b428d5eb3e6bd358e00 Mon Sep 17 00:00:00 2001 From: YongCho Date: Mon, 6 Apr 2015 22:59:05 -0400 Subject: [PATCH 5/9] Update README.md --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index fa319a2..8ef5c65 100644 --- a/README.md +++ b/README.md @@ -13,6 +13,9 @@ Project Proposal is due 2015-04-08 at 8am * Higher-Order-Procedures discussed in class such as map, filter, zip will be used. We also need to keep the substitution model in mind when creating new data from original data. * As a team we need to consider what level of abstraction to implement for our project. +* Technique to create an object with local state variables and procedures will be used to maintain a database of mailing list entries consisting of names and addresses, as well as procedures to access and modify them. +* Multiple threads may be necessary to be able to schedule and execute tests with different intervals in parallel. + ### Data set or other source materials From af86a1c6950c7e8dbc9e69c13c254c61fa38019a Mon Sep 17 00:00:00 2001 From: Roy Van Liew Date: Tue, 7 Apr 2015 09:59:52 -0400 Subject: [PATCH 6/9] freds-db has too many extra cases for tests split across multiple lines, ps5 is a better aim --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index fa319a2..126c9c6 100644 --- a/README.md +++ b/README.md @@ -45,7 +45,7 @@ An excel spreadsheet representing a calendar will be used as a planner. Some thi * The user doesn't need to specify if the test area loads in a Bottlenose test suite. We already assume the QA Engineer knows how to create test suites and test areas, we are just using Bottlenose tests as the suites. The key is to have properly formatted test area files, and any kind of suite can be run. First Milestone (04-13) -* Bottle-Racket will be able to convert the first 3 assignments along with freds-db (that one requires loading in definitions from another file). +* Bottle-Racket will be able to convert the first 3 assignments along with ps5. * Test results can be sent out to the QA Email group by reading in the test result files generated from the test-running scripts created by Test-Capture. * Racket-Doc will be able to extract user-specified attributes from .rkt files, and save them to file. The web pages should be fully navigable (on a local host), although they will contain hard-coded data. * User interface and file database for managing and storing mailing lists, as well as sending emails with a test result will be fully functional. From e71e381790cf0a89c09fdd056f306b3f449907e3 Mon Sep 17 00:00:00 2001 From: Roy Van Liew Date: Tue, 7 Apr 2015 10:01:55 -0400 Subject: [PATCH 7/9] freds db has too many special cases regarding test cases across multiple lines, better goal is ps5 --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 037fb0d..6cf5ea2 100644 --- a/README.md +++ b/README.md @@ -36,7 +36,7 @@ Project Proposal is due 2015-04-08 at 8am ### Evaluation of Results -* Bottle-Racket will be able to convert the first 4 assignment test files. +* Bottle-Racket will be able to convert the first 3 assignments along with ps5. * Scheduler will be able to successfully run test-running scripts in consistent intervals, even when the mailing list associated with the test area is updated between consecutive test run-ups and when the source code tested is changed. * Email module will be able to detect when a user enters an incorrect email address or when a database stored in the user's storage is corrupted between the program run-ups, and notify the user of the invalid entries. * Racket-Doc will be able to successfully extract the user-specified attributes, save it to file, and display it in web pages running on the local host. From 60ae443cc126e0622dc69bfd6941b4bdb072bba2 Mon Sep 17 00:00:00 2001 From: Roy Van Liew Date: Tue, 7 Apr 2015 20:04:27 -0400 Subject: [PATCH 8/9] Polished up Readme --- README.md | 43 +++++++++++++++++++++---------------------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/README.md b/README.md index 6cf5ea2..97c5a0c 100644 --- a/README.md +++ b/README.md @@ -4,31 +4,30 @@ Project Proposal is due 2015-04-08 at 8am # Project Title: Racket-QA ### Problem Statement -* Racket has a unit testing library RackUnit which can run test cases and test suites, but it seems incomplete as an API from a QA Engineer standpoint and its documentation is poor. We want to create some well-documented user-friendly utilities that a QA Engineer could use in Racket. -* Someone can use RackUnit to run tests, but can't send those results out to a QA team and can't schedule when the tests should be run. -* Along with encouraging test-driven development, there should also be standards established for documentation. Racket-Doc is a component of this project which uses an interactive GUI to extract documentation and user-specified attributes from `.rkt` source files, and save this to file for future preview as well as display it as styled text in web pages. -* The above three points are the big picture focus, but in our case we are using bottlenose test cases from this course as the basis of individual test suites to run. The problem with the current Perl test cases is that if people want to test their code on the assignments, they have to test one case at a time manually which is tedious and inefficient. Using RackUnit, all test cases can run at once and the person sees exactly which cases failed and why; running the Perl test cases just say "not ok" which isn't helpful, and those scripts take a while to run. +* Racket has a unit testing library `RackUnit` which can run test cases and test suites, but it seems incomplete as an API from a QA Engineer standpoint and its documentation is poor. We want to create some well-documented user-friendly utilities that a QA Engineer could use in Racket. +* Someone can use `RackUnit` to run tests, but can't send those results out to a QA team and can't schedule when the tests should be run. +* Along with encouraging test-driven development, there should also be standards established for documentation. `Racket-Doc` is a component of this project which uses an interactive GUI to extract documentation and user-specified attributes from `.rkt` source files, and save this to file for future preview as well as display it as styled text in web pages. +* The above three points are the big picture focus, but in our case we are using bottlenose test cases from this course as the basis of individual test suites to run. The problem with the current Perl test cases is that if people want to test their code on the assignments, they have to test one case at a time manually which is tedious and inefficient. Using `RackUnit`, all test cases can run at once and the person sees exactly which cases failed and why; running the Perl test cases just say "not ok" which doesn't give much information, and those scripts take a while to run. ### Problem Analysis * Higher-Order-Procedures discussed in class such as map, filter, zip will be used. We also need to keep the substitution model in mind when creating new data from original data. * As a team we need to consider what level of abstraction to implement for our project. -* Technique to create an object with local state variables and procedures will be used to maintain a database of mailing list entries consisting of names and addresses, as well as procedures to access and modify them. +* Techniques to create an object with local state variables and procedures will be used to maintain a database of mailing list entries consisting of names and addresses, as well as procedures to access and modify them. * Multiple threads may be necessary to be able to schedule and execute tests with different intervals in parallel. - ### Data set or other source materials -* For the most part the scripts will be working with existing data from files stored on the computer. This is especially true for Bottle-Racket. +* The scripts will be working with existing data from files stored on the computer. This is especially true for `Bottle-Racket`. * `Bottle-Racket` takes a source Racket assignment file and a Bottlenose Perl test file from the computer as data. The lines from these files are read as strings, and HOP are used to work with the data as lists of strings. New files will be generated such as the test suite and test area file. -* `Test-Capture` is a utility that will take the test area files generated from Bottle-Racket to create test-running scripts that save test results to file and can be sent out to a team via email. +* `Test-Capture` is a utility that will take the test area files generated from `Bottle-Racket` to create test-running scripts that save test results to file and can be sent out to a team via email. * `Racket-Doc` recieves a .rkt file, or a directory containing .rkt source files. These must be provided by the user (although example test files will be provided). Also, the resulting documentation is displayed in a web page, so a web browser must be installed (for testing purposes we are using Firefox). * `QA-Email` will get the email body from the test results file generated by a test-running script that's used after `Bottle-Racket` creates a test area file. ### Deliverable and Demonstration * The program `Bottle-Racket` is a GUI that will be able to take a bottlenose assignment file and convert it into a test suite file that is also specified in a generated test area file. Then `Test-Capture` is a GUI used to make a test-running script for that test area file which specifies the test suite to run. -* In addition to Bottlenose tests, the project will be capable of running a properly formatted RackUnit test area with a test suite provided by the user. +* In addition to Bottlenose tests, the project will be capable of running a properly formatted `RackUnit` test area with a test suite provided by the user. * The project will provide a file containing the results for the test area, and this file can be sent as an email to the development team. * The project will provide `Scheduler`, a GUI to schedule a test area to be run automatically with a specified test-running script. This feature is targeted mainly for regression testing of a project involving multiple developers. * The project will provide `QA-Email`, a GUI to configure an email database associated with each test area, which will be used to send out a scheduled test result upon the user's request. @@ -36,27 +35,27 @@ Project Proposal is due 2015-04-08 at 8am ### Evaluation of Results -* Bottle-Racket will be able to convert the first 3 assignments along with ps5. -* Scheduler will be able to successfully run test-running scripts in consistent intervals, even when the mailing list associated with the test area is updated between consecutive test run-ups and when the source code tested is changed. -* Email module will be able to detect when a user enters an incorrect email address or when a database stored in the user's storage is corrupted between the program run-ups, and notify the user of the invalid entries. -* Racket-Doc will be able to successfully extract the user-specified attributes, save it to file, and display it in web pages running on the local host. +* `Bottle-Racket` will be able to convert the first 3 assignments along with ps5. +* `Scheduler` will be able to successfully run test-running scripts in consistent intervals, even when the mailing list associated with the test area is updated between consecutive test run-ups and when the source code tested is changed. +* `QA-Email` will be able to detect when a user enters an incorrect email address or when a database stored in the user's storage is corrupted between the program run-ups, and notify the user of the invalid entries. +* `Racket-Doc` will be able to successfully extract the user-specified attributes, save it to file, and display it in web pages running on the local host. ## Work Plan and Schedule An excel spreadsheet representing a calendar will be used as a planner. Some things to consider: -* Scheduler will be implemented in the Second Milestone. +* `Scheduler` will be implemented in the Second Milestone. * The user doesn't need to specify if the test area loads in a Bottlenose test suite. We already assume the QA Engineer knows how to create test suites and test areas, we are just using Bottlenose tests as the suites. The key is to have properly formatted test area files, and any kind of suite can be run. First Milestone (04-13) -* Bottle-Racket will be able to convert the first 3 assignments along with ps5. -* Test results can be sent out to the QA Email group by reading in the test result files generated from the test-running scripts created by Test-Capture. -* Racket-Doc will be able to extract user-specified attributes from .rkt files, and save them to file. The web pages should be fully navigable (on a local host), although they will contain hard-coded data. -* User interface and file database for managing and storing mailing lists, as well as sending emails with a test result will be fully functional. +* `Bottle-Racket` will be able to convert the first 3 assignments along with ps5. +* Test results can be sent out to the QA Email group by reading in the test result files generated from the test-running scripts created by `Test-Capture`. +* `Racket-Doc` will be able to extract user-specified attributes from .rkt files, and save them to file. The web pages should be fully navigable (on a local host), although they will contain hard-coded data. +* For `QA-Email`, a user interface and file database for managing and storing mailing lists, as well as sending emails with a test result will be fully functional. Second Milestone (04-21) -* Racket-Doc will be able successfully port the extracted data to the web pages. -* The project will be able to run a Bottlenose test or other RackUnit test upon users' choice. -* Test scheduler will be created and tested with capability to send emails automatically after the scheduled test run-up. +* `Racket-Doc` will be able successfully port the extracted data to the web pages. +* The project will be able to run a Bottlenose test or other `RackUnit` test upon users' choice. +* `Scheduler` will be created and tested with capability to send emails automatically after the scheduled test run-up. ## Group Responsibilities @@ -65,7 +64,7 @@ Second Milestone (04-21) * James will work on `Racket-Doc`. ## Proposal Presentation Link -[**Racket-QA PowerPoint**][powerpoint] +The [**Racket-QA PowerPoint**][powerpoint] provides some visuals of the concept behind these project components. [powerpoint]: https://docs.google.com/presentation/d/1Ff5LjW92cEDqhPJGla6IjBosKEh1DuKNqqaBsNtIqRg/edit?usp=sharing From cf53dbb23d9d9be4922e2665ad03f5795de9c62d Mon Sep 17 00:00:00 2001 From: Roy Van Liew Date: Tue, 7 Apr 2015 20:09:02 -0400 Subject: [PATCH 9/9] This looks like the final version, clarified what will be changed in the bottlenose tests --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 97c5a0c..5bfd19c 100644 --- a/README.md +++ b/README.md @@ -35,7 +35,7 @@ Project Proposal is due 2015-04-08 at 8am ### Evaluation of Results -* `Bottle-Racket` will be able to convert the first 3 assignments along with ps5. +* `Bottle-Racket` will be able to convert the first 3 assignments along with ps5. ps5b's test file will need to be modified since the procedures in 2.57 and 2.58 have the same name and will be duplicate definitions, and ps3a's print test will be changed to not do a print. * `Scheduler` will be able to successfully run test-running scripts in consistent intervals, even when the mailing list associated with the test area is updated between consecutive test run-ups and when the source code tested is changed. * `QA-Email` will be able to detect when a user enters an incorrect email address or when a database stored in the user's storage is corrupted between the program run-ups, and notify the user of the invalid entries. * `Racket-Doc` will be able to successfully extract the user-specified attributes, save it to file, and display it in web pages running on the local host. @@ -47,7 +47,7 @@ An excel spreadsheet representing a calendar will be used as a planner. Some thi * The user doesn't need to specify if the test area loads in a Bottlenose test suite. We already assume the QA Engineer knows how to create test suites and test areas, we are just using Bottlenose tests as the suites. The key is to have properly formatted test area files, and any kind of suite can be run. First Milestone (04-13) -* `Bottle-Racket` will be able to convert the first 3 assignments along with ps5. +* `Bottle-Racket` will be able to convert the first 3 assignments along with ps5. ps5b's test file will need to be modified since the procedures in 2.57 and 2.58 have the same name and will be duplicate definitions, and ps3a's print test will be changed to not do a print. * Test results can be sent out to the QA Email group by reading in the test result files generated from the test-running scripts created by `Test-Capture`. * `Racket-Doc` will be able to extract user-specified attributes from .rkt files, and save them to file. The web pages should be fully navigable (on a local host), although they will contain hard-coded data. * For `QA-Email`, a user interface and file database for managing and storing mailing lists, as well as sending emails with a test result will be fully functional.