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

toml-test datetime cases use tomlkit's own parse_rfc3339 as the expected value, so they cannot detect datetime parsing bugs

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

Maintainer thường phản hồi trong vòng 1 ngày

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

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
68/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
testing-qa

Hướng nghiên cứu

Bắt đầu với tests/test_toml_tests.py và các kỳ vọng của parse_rfc3339, sau đó chạy các bài kiểm thử datetime, bao gồm test_parse_rfc3339_datetime. Làm cho các kỳ vọng datetime độc lập với parser và bổ sung coverage cho offset +05:30; nếu xử lý issue liên quan đến helper, hãy kiểm tra tests/util.py::elementary_test và các trường hợp test_*_unwrap, với các assertion về giá trị là tiêu chí hoàn thành.

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

Mô tả

While running a mutation-based check of the test suite at 4b38bec, one structural gap stood out and seemed worth reporting. Nothing here is a bug in tomlkit's code — every mutation below was a deliberate break, and the code as shipped is correct.

What was observed

tests/test_toml_tests.py builds the expected value for every datetime-typed case with tomlkit._utils.parse_rfc3339:

stypes = {
    ...
    "datetime": parse_rfc3339,
    "datetime-local": parse_rfc3339,
    "date-local": parse_rfc3339,
    "time-local": parse_rfc3339,
}

That is the function under test, so for those four types the parser and the expectation drift together. Breaking the negative-offset sign in parse_rfc3339 (if sign == "-": offset = -offset → never negating) produced:

red
toml-test compliance cases (680) 0
hand-written tests (378) 3 (test_parse_rfc3339_datetime ×2, test_datetimes_behave_like_datetimes)

By contrast, dropping the integer sign in the parser reddened 6 compliance cases and untranslated string escapes 7 — for int and str the corpus is an independent oracle. For datetimes it is not, and the entire guard is three hand-written tests.

Related, smaller: no input anywhere in tests/ (hand-written or corpus) carries a non-zero minute offset, so +05:30 being parsed as +05:00 (dropping minute_offset from the timedelta) survives the whole suite.

Possible fix

Build datetime expectations independently — datetime.fromisoformat accepts RFC 3339 on Python 3.11+ and the project already requires ≥3.9 with a compat shim, or a tiny hand-rolled regex as the toml-test JSON format is fixed — and add one +05:30-style case to test_parse_rfc3339_datetime.

Also noticed

tests/util.py::elementary_test asserts isinstance(v.unwrap(), unwrapped_type) only, so the nine test_*_unwrap tests detect a wrong type but not a wrong value: Bool.unwrap returning not bool(self) passes test_true_unwrap and test_false_unwrap. Passing the expected value to the helper would close that.

Full write-up with the mutation spec and per-test results, reproducible against 4b38bec: https://github.com/ArnauFerma/falsifiable-tests/blob/main/case-studies/tomlkit.md

Happy to send a PR for either if you'd take one.

Ngôn ngữ chính
Python
Star
850
Fork
163
Merge trung bình
13 phút
Pull request đã merge (30 ngày)
2

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

Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

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 python-poetry/tomlkit

Tất cả issue của python-poetry/tomlkit

Issue tương tự

Thêm issue về Python

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.