Project 1A: Build Checkpoint¶
Build Checkpoint – 5 points – due Friday, January 19th, 11:59pm
Fork the class-specific repository into your personal GitHub account.
Even though this project is based off of an active open source project, we have made significant changes to ensure its suitability for our class. As such, be sure you are forking off of CMU-313/NodeBB and direct any questions to course staff. Do not contact the maintainers of NodeBB for assistance with your homework questions.
Ensure that GitHub Actions are enabled (click the green button under the "Actions" tab), then follow the below installation instructions based on your computer's operating system:
Once you have run NodeBB successfully, you should be able to navigate to http://localhost:4567 and see the main forum page. By default, NodeBB will be deployed to port
4567 on your machine. You may change this port number (e.g. to avoid conflict with another process running on your machine).
In this class, we do expect students to first try debugging errors on their own; this includes following stack traces, searching up error strings and unfamiliar outputs, etc. If you do get stuck, or if the process of installing and running NodeBB is taking you more than a few hours, stop and ask for help on Slack!
Take some time to click through the pages and explore the different features that NodeBB has to offer.
When working on an existing codebase, especially in a collaborative setting, we want to ensure that none of our changes introduce unexpected bugs or issues for other developers. To fulfill these goals, we often use different tools to help us evaluate our code. Luckily, NodeBB is already packaged with a number of neat tools!
Follow the Development Tools section in the repository README to run both the linter and testing tools provided by NodeBB on your computer. Without any changes to the repository, both tools should pass.
After the test suite finishes running, NodeBB will also generate a code coverage report. This report gives you measurements with regards to what percentage of the codebase is covered by the test suite. Open the
index.html file in the
coverage folder to see the full report.
As this is an existing codebase with a decently-sized test suite, you should expect to see a relatively high percentage of coverage, i.e. the majority of the bars/cells displayed should be green.
If you are seeing a lot of red bars, it may mean that the test suite was not run properly. Double-check that all of the tests passed and that there were no failures.
More on Analysis Tools
A linter is a tool that directly analyzes your source code for common errors. A test suite is a set of test cases that you write for a software program to show that it has some specified set of behaviors; our testing tool provides a framework to structure our test cases, runs the test suite, and generates a report of which tests pass/fail.
We will do a more in-depth exploration of analysis tools later in the course. For now, just know that these tools exist for you to use in evaluating your code.
Build Checkpoint (5 pts)¶
Upon completing the above steps, take screenshots of
- the home page of NodeBB, and
- the coverage report generated by the coverage tool
opened in your browser. Be sure the URL is clearly visible in both screenshots (i.e.
localhost:4567 and the file path to your coverage file), so we can confirm that you have everything running locally.
Submit the two screenshots to Gradescope.
To receive full credit for this checkpoint, we expect:
- A Gradescope submission of two screenshots showing a local running build of NodeBB and the coverage report within a browser