UCL / UCL/rsd-engineeringcourse

"Testing Basics" page

Open
#89 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

2018-19
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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.