[issue-12] docs: catalog new scanner codes + fix coverage table (#12)#13
Conversation
Mirror the codes the three scanners just shipped into the catalog pages (EN + PT): - Python: C49, C50, C51, C52, C55. - JS/TS: JS25, JS26, JS27, JS29, JS30, JS31; C8b and C11a into the shared-codes table. - Robot: R8, R8b into the Robot-specific section; C9b and C11a into the shared-codes table. Coverage table (vinicq#12): map the Robot codes into F1-F8 (the R-empty placeholder is gone), add JS23/JS24, correct the PL list to PL1/2/7/8/9/10, and fold in every newly-cataloged code so the per-family table matches the catalog pages. EN and PT stay in lockstep. Also lands the detection-tools references section in credits.md (tsDetect, PyNose, JNose, DARTS, TestAXE, TestLint and the ML-detection critique), drafted earlier and left pending. Closes vinicq#12. Co-authored-by: homesellerq-coder <294912019+homesellerq-coder@users.noreply.github.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7b88e34479
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| `with pytest.raises(E):` (or `pytest.warns`) whose body is empty (`pass`, `...`, a comment). | ||
| No call is made inside the block, so the call that should raise never runs and the context | ||
| manager has nothing to catch. Always green. |
There was a problem hiding this comment.
For the empty pytest.raises / pytest.warns body described here (pass, ..., or only a comment), pytest does not pass green: it fails with DID NOT RAISE or DID NOT WARN because no exception/warning was observed. Cataloging this as a HIGH F1 false-green will misclassify tests that are already red and also overstate coverage via the new C51 entry in the coverage table.
Useful? React with 👍 / 👎.
| `caplog` is read (`caplog.records`, `caplog.text`) or `self.assertLogs(...)` is entered, but the | ||
| captured output is never asserted: no comparison on the records, messages, or levels. The capture | ||
| ran and had no effect on pass/fail. The logging sibling of C31. |
There was a problem hiding this comment.
When this pattern is self.assertLogs(...), the context manager itself asserts that at least one log at the requested level is emitted; if none are emitted, unittest records a failure. Flagging every assertLogs block whose captured records are not inspected will report tests whose intended oracle is simply “logging happened” as F1/no-oracle, and the claim that the capture has no pass/fail effect is false.
Useful? React with 👍 / 👎.
| Both operands are fixed at parse time: `expect(2).toBe(3)`, chai `expect(1).to.equal(1)`. The | ||
| assertion does not touch the unit under test, so it is either always-true or always-false by | ||
| construction, never a check on real behaviour. |
There was a problem hiding this comment.
With the documented expect(2).toBe(3) case, Jest/Chai fail immediately, so that input is not a HIGH F3 false-green (the docs define F3 as always passes and HIGH as a definite false-green). Including always-false literal assertions in JS30 would make the scanner/docs report red tests as false-green and inflate the F3 coverage; restrict this code to provably true literal assertions or move unequal literals to diagnostics.
Useful? React with 👍 / 👎.
| | **F2** | The check exists but never runs | `C1`, `C3`, `C20`, `C21`, `C22`, `C43`, `CC`, `JS5`, `JS7`, `JS9`, `JS11`, `JS25`, `JS26`, `JS29`, `JS31`, `R8`, `R8b` | static | | ||
| | **F3** | The check is trivial (always passes) | `C5`, `C6`, `C6c`, `C7`, `C8`, `C8b`, `C11a`, `C18`, `C34`, `C42`, `C44`, `C52`, `JS15`, `JS21`, `JS30`, `R1`, `R6` | static | | ||
| | **F4** | Checks the wrong thing | `C9`, `C9b`, `C19`, `C28`, `C49`, `C55`, `JS8`, `JS24`, `JS27`; semantic case 18, parts of `C6` / `C33` / the snapshot codes | static (partial) + skill | | ||
| | **F5** | Drops out of the count (skip / not collected) | `C4`, `C4b`, `C25`, `C32`, `C38`, `C45`, `JS1`, `JS4`, `JS22`, `JS23`, `R3`, `R5`; project layer: `PL1`, `PL2`, `PL7`, `PL8`, `PL9`, `PL10` | static + project layer | |
There was a problem hiding this comment.
When expect.assertions(N) is higher than the number of assertions that actually run, Jest fails the test at the end of execution; it does not silently skip or pass green. Adding JS23 to the F5 coverage row therefore counts a red test as shipped false-green coverage and makes the table overstate what the ecosystem detects.
Useful? React with 👍 / 👎.
| The only assertion is `toHaveBeenCalled` / `toHaveBeenCalledWith` / `toHaveBeenCalledTimes` on a | ||
| mock created in the test (`jest.fn()` / `vi.fn()`). It verifies the test's own wiring, that the | ||
| double was invoked, not that the unit produced the right result. |
There was a problem hiding this comment.
When the locally-created mock is passed into the unit as a callback or dependency, toHaveBeenCalledWith / toHaveBeenCalledTimes can be the observable contract (for example, verifying that the unit calls a notifier with the right payload). Describing every sole call assertion on jest.fn() / vi.fn() as F4 will warn on legitimate interaction tests unless the rule is limited to mocks of the unit under test or doubles invoked only by the test itself.
Useful? React with 👍 / 👎.
1 participant
Mirrors the just-merged scanner codes into the catalog (EN+PT): Python C49-C55, JS25-31 + C8b/C11a, Robot R8/R8b + C9b/C11a. Coverage table (#12): Robot codes mapped to F1-F8, JS23/JS24 added, PL list corrected to PL1/2/7/8/9/10, every catalog code reflected. Plus the detection-tools references in credits.md. mkdocs build --strict: PASS. Closes #12.