CSC 217 Lab 12 Testing
As with any software development project, you must test your code to know if it meets the requirements and design. You have run black box tests on your new functionality and bug fixes. Now you will ensure no regressions in functionality and ensure that you’re maintaining sufficient coverage PackScheduler.
PackScheduler Coverage
Ensure that all non-UI classes have at least 80% statement coverage and that all unit tests are continuing to pass. Add any needed tests to cover at least 80% of the statements.
The work that you are completing for the GUI shouldn’t lead to any regression in functionality, but if there is a regression, you’ll need to find and fix it.
System Testing and Debugging
Run all of your prior black box tests on the PackSchedule project to ensure that the addition of the new GUI elements hasn’t broken any other GUI functionality.
- Run the tests on the
PackSchedulerproject. If the test fails, debug your system until it passes. - Report the actual results of execution after debugging your system.
- Create tests for the new functionality related to faculty.
The following files are needed for testing.
- faculty_records_extended.txt
- student_records.txt
- course_records.txt
- expected_course_catalog.txt
- expected_course_records.txt
- starter_course_records.txt
- t19_student_directory.txt
- t39_course_catalog.txt
- faculty_records.txt
- expected_faculty_records.txt
- invalid_faculty_records.txt
- expected_full_faculty_records.txt
Push to GitHub
Push your PackScheduler project to GitHub
- Add the unstaged changes to the index.
- Commit and push changes. Remember to use a meaningful commit message describing how you have changed the code.
Reminder: Staging and Pushing to GitHub
GitHub Resources:
Check Jenkins
If you have test failures, use the feedback from Jenkins to help you resolve the issues.
Reminder: Interpreting Jenkins
Check the following items on Jenkins for your last build and use the results to estimate your grade: