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

Support explicitly disposing test dependencies

Đang mở
  • Có gì không ổn?
#95 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
30/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
csharp
Lĩnh vực
testing

Hướng nghiên cứu

Bắt đầu bằng cách xem xét các tùy chọn Add(Async)TestBlock và Add(Async)FinallyBlocks, sau đó kiểm tra hành vi của TestCase được mô tả trong issue. Thay đổi hoàn tất cần thiết lập và ghi lại một phương pháp giải phóng có thể dọn dẹp đáng tin cậy các browser context Playwright của từng test và có thể cả browser, mà không che giấu các dependency.

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

Mô tả

Traditionally, we don't use dependency injection for objects that need to be explicitly disposed (e.g. rest clients that we want to stick around for all tests to reuse.) They are handled as part of the unit test method lifecycle using unit test setup/teardown. This works fine in most cases, but has always been kinda shaky as it can easily break the TestFramework concept of not hiding dependencies away.

However, we recently ran into a situation migrating a project from Selenium to Playwright, and had issues with how that project was managing disposable objects. Hooking playwright into the existing framework would involve a lot of effort, but Injecting the playwright disposables into DI doesn't properly work as we declare test dependencies as singletons so it doesn't reliably get cleaned up at the end of a test (playwright's instance is static, that may be the difficulty here.)

Consideration: For Playwright specifically, the parent Playwright object is okay to leave around for the entire test run, but we really want to destroy the browser context (and possibly the browser itself) between each run so that we're NOT just adding more open browsers on longer test runs.

Some possible fixes:

  • Do nothing. Create a finally block to dispose the context (and possibly browser)
    • Pro: It's easy and visible
    • Con: for new projects someone will need to know to do this
      • Possible mitigation:
        • Update documentation and provide an example in the Examples project
        • Write an analyzer that throws an informational message (already have other items that would be good for an analyzer, e.g. test blocks with no execute method.)
  • Change or add Add(Async)TestBlock and Add(Async)FinallyBlocks that use a scoped lifetime.
    • Pro: automagically handled
    • Con: Could be unintentional behavior changes if we update existing methods, or would require someone to know the difference between scoped and singleton lifetimes (or what's disposable and what isn't) if we add new methods, which breaks the concept of not requiring and automated tester to know those specifics
      • Possible mitigation:
        • Four unique methods, something like Add(Async)DisposableTest(Finally)Block
        • Just change the existing methods to use scoped instead of singleton
        • Update the TestCase behavior to search through the container for any singletons that implement IDisposable and explicitly call them before going into the logic to throw any exceptions that occurred
Ngôn ngữ chính
C#
Star
1
Fork
1
Không có pull request nào được merge trong 30 ngày

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 IntelliTect/TestTools.TestFramework

Tất cả issue của IntelliTect/TestTools.TestFramework

Issue tương tự

Thêm issue về C#

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.