Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Lint: flag invariants and action.preserves not covered by a test

Đang mở
  • Có gì không ổn?
#6 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
45/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
go
Lĩnh vực
devtools, testing

Hướng nghiên cứu

Trước tiên, hãy giải quyết câu hỏi về quy ước marker so với sidecar-manifest, bao gồm mối liên hệ của nó với issue #5 và đầu vào YAML duy nhất. Sau đó, đọc các quy ước lint nội bộ hiện có và các bài kiểm thử golden/lint-model, rồi ghi lại quyết định trong audits/ nếu phù hợp. Được xem là hoàn tất khi một phát hiện về tính đầy đủ hoặc khả năng truy vết xác định các mục invariant.id và action.preserves không được tham chiếu, với hành vi cảnh báo theo mặc định và hành vi strict-mode được bao phủ bởi các bài kiểm thử.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement

Summary

Add a lint/completeness signal that flags every invariant.id (entity-level and model-level) and every action.preserves entry that is not referenced by any test in the repo. This is the durable, on-mission version of "wire testing in from the model": modelith already emits completeness findings (e.g. entities with no invariants, entities no scenario touches). This extends that discipline outward to the model↔test relationship.

Why a checker, not a generator

The tempting version — generate a skipped t.Skip test stub per invariant — is a false green: coverage tools count the stub as present, go test passes, CI is green, and the test asserts nothing. A directory of 40 skipped invariant tests reads as "we have invariant coverage" while proving nothing. Worse, the model↔test link is by invariant.id, and renaming an invariant is a first-class modelith operation (IDs sharpen as understanding does) — a generator would then clobber human-written bodies or orphan them.

Checking references instead of generating code turns the false-green inside out: rather than emitting stubs that lie, flag the invariants that lack a real test. It's deterministic, its output is disposable (a finding, not owned code), and it survives renames because it checks references rather than owning generated files.

Open design question (must resolve before building)

modelith today reads a single YAML file; traceability requires knowing what tests exist. Two candidate input surfaces:

  1. Marker convention — tests reference the invariant id in a structured, greppable way (e.g. a comment token or test-name convention); modelith scans a configured test path.
  2. Sidecar manifest — a small mapping file (invariant-id → test reference) that the #5 skill emits and the engineer maintains; modelith validates coverage against it.

Option 2 keeps modelith's "reads declared inputs" character intact and pairs naturally with #5; option 1 is lower-friction but expands modelith into a repo scanner. Decide this first — it's the crux of whether this stays on-mission.

Scope

  • New completeness (or a new "traceability") category finding.
  • Likely warning severity by default (an unproven invariant is a gap, not a structural error), with an opt-in strict mode consistent with how completeness is already treated.
  • Golden/lint-model test coverage consistent with the existing internal/lint conventions.

Relationship to the other issues

  • Consumes the traceability convention produced by #5.
  • Replaces the discarded "generate skipped test scaffolds" idea (former Tier 2).

Background

Descends from "Tier 2" of a three-tier design discussion, reshaped by a skeptic pass from generate stubs to check references. Consider recording the decision in audits/.

🤖 Generated with Claude Code

Ngôn ngữ chính
Go
Star
35
Fork
5
Merge trung bình
5 giờ 7 phút
Pull request đã merge (30 ngày)
6

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của stacklok/modelith

Tất cả issue của stacklok/modelith

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.