UCL / UCL/rsd-engineeringcourse
"Testing Basics" page
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 133
- Forks
- 111
- PR merge metrics
- No merged PRs in 30d
Description
http://github-pages.ucl.ac.uk/rsd-engineeringcourse/ch03tests/01testingbasics.html
This page is generally very low on text, which for me makes it hard to read, even for lecture notes. I think we could easily expand some of the bullet points into at least full sentences.
- A few reasons to do testing:
- "lazyness" -> laziness
- "reproducible debugging": not sure I understand this
- Tests at different scales: we could maybe have a small example to illustrate where the different kinds of tests apply (either explained in a few lines of natural language, or with an outline of a class and methods)
- Legacy code hardening: last bullet point needs some rewording/typo fixing
- Testing vocabulary: Generalise explanation of fixture to "external resources (like input data) that the test needs", or something similar
- Branch coverage: maybe explain this a bit more. Phrasing ("Is there a test for both energy > 0 and energy <= 0?") is a little ambiguous. Maybe "Is there a test for each of the cases?" or "Are both cases covered by tests?" or "Is there a test (not necessarily the same!) for both energy > 0 and energy <= 0?"
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Open the “Testing Basics” page at the linked URL and review the sections on testing reasons, test scales, legacy code hardening, testing vocabulary, and branch coverage. Expand sparse bullet points into clearer prose, fix the noted typo and wording, and add a small test-scale example if appropriate. Done means the page is easier to read and the listed ambiguities are resolved.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100