如何运行xctest以获取返回viewController func

发布于 2025-01-31 15:16:15 字数 1101 浏览 3 评论 0 原文

如何为下面的代码编写Xctestcase

class HelpViewUseCase: HelpUseCaseProtocol, SubscriptionsHelpProtocol, ProfileHelpProtocol {
      func getHelpViewController() -> UIViewController {
        HelpViewController()
      }
    }

另一个我无法测试的类,

class UnifiedDirectAppointmentViewModel: UnifiedHistoryRowViewModel {       
      var rowType: UnifiedHistoryTableRowType {
        .directBooking
      }
        
          let appointmentResponse: DirectBookingInfoModel
        
      init?(forRowModel rowModel: UnifiedHistoryRowModel) {
        guard let data = rowModel.data.data as? DirectBookingInfoModel else {
          Log.error("Failed init for appointment \(rowModel)")
          return nil
        }
        appointmentResponse = data
      }
        }
        
extension UnifiedDirectAppointmentViewModel {
      var reuseIdentifier: String {
        DirectAppointmentTableViewCell.identifier
      }
      var bundle: Bundle? {
        Bundle(for: DirectAppointmentTableViewCell.self)
      }
    }

我是新来的单元测试,并且想知道如何测试Aove类。事先感谢您的建议和帮助

How to write XCTestCase for below code

class HelpViewUseCase: HelpUseCaseProtocol, SubscriptionsHelpProtocol, ProfileHelpProtocol {
      func getHelpViewController() -> UIViewController {
        HelpViewController()
      }
    }

Another class which I'm unable to test

class UnifiedDirectAppointmentViewModel: UnifiedHistoryRowViewModel {       
      var rowType: UnifiedHistoryTableRowType {
        .directBooking
      }
        
          let appointmentResponse: DirectBookingInfoModel
        
      init?(forRowModel rowModel: UnifiedHistoryRowModel) {
        guard let data = rowModel.data.data as? DirectBookingInfoModel else {
          Log.error("Failed init for appointment \(rowModel)")
          return nil
        }
        appointmentResponse = data
      }
        }
        
extension UnifiedDirectAppointmentViewModel {
      var reuseIdentifier: String {
        DirectAppointmentTableViewCell.identifier
      }
      var bundle: Bundle? {
        Bundle(for: DirectAppointmentTableViewCell.self)
      }
    }

I'm new to unit test and was wondering how can I test aove classes. Thanks in advance for the suggestions and help

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

你的笑 2025-02-07 15:16:15

单位测试(或“ microtest “”)应该

  • :安排)
  • 调用我们要锻炼的行为(ACT)
  • 确认预期结果(断言)

这是一个通常称为3 A的序列,因为 a rrange, a ct, a ssert。我喜欢用空白行分开它们,以清楚每条测试代码正在扮演的角色。

对于您的第一个示例,您拥有 gethelpviewController()返回 uiviewController ,特别是 helpViewController 。因此,我们可以如下测试。 (我通常不使用注释,但在这里这样做是为您确定每行的目的。)

// The class creates a test suite, a collection of tests.
// Subclass XCTestCase.
// Name it after the type you want to test, and add "Tests".
// final is not required, but can give a minor speed improvement.
final class HelpViewUseCaseTests: XCTestCase {

    // In XCTest, a test method must start with the letters "test".
    // Name it for the behavior you want to test.
    // In this case, the name of the method is good enough.
    // The underscore is not required. I just like the separation in the name.
    // I declare all my test methods as throwing because it
    // makes it easier to use throwing test helpers like XCTUnwrap.
    func test_getHelpViewController() throws {
        // Arrange
        let useCase = HelpViewUseCase()

        // Act
        let result = useCase.getHelpViewController()

        // Assert
        XCTAssertTrue(
            result is HelpViewController,
            "Expected a HelpViewController, but was a \(type(of: result))"
        )
    }
}

我在 xctasserttrue 中添加了一条消息,因为如果失败了,我想知道更多的信息”这不是真的。”我想知道为什么。因此,我有消息说明期望和实际类型。尝试通过返回错误类型的视图控制器来查看消息的外观来打破生产代码。 (在编写测试时,重要的是要以某种方式检查它是否有效,并且如果失败给出了足够的信息。)

您的第二个示例确实是一个单独的问题,不应将其他问题引入其他问题。随意直接给我发消息。

我写了一本书,可以帮助您开始在Swift中进行单元测试。 有关详细信息,请参见我的个人资料

A unit test (or "microtest") should:

  • Set up something to call (Arrange)
  • Call the behavior we want to exercise (Act)
  • Confirm the expected result (Assert)

This is a sequence often called the 3 A's, for Arrange, Act, Assert. I like to separate them with blank lines to make it clear what role each line of test code is playing.

For your first example, you have getHelpViewController() which returns a UIViewController, specifically a HelpViewController. So we can test that as follows. (I don't normally use comments, but did so here to identify the purpose of each line for you.)

// The class creates a test suite, a collection of tests.
// Subclass XCTestCase.
// Name it after the type you want to test, and add "Tests".
// final is not required, but can give a minor speed improvement.
final class HelpViewUseCaseTests: XCTestCase {

    // In XCTest, a test method must start with the letters "test".
    // Name it for the behavior you want to test.
    // In this case, the name of the method is good enough.
    // The underscore is not required. I just like the separation in the name.
    // I declare all my test methods as throwing because it
    // makes it easier to use throwing test helpers like XCTUnwrap.
    func test_getHelpViewController() throws {
        // Arrange
        let useCase = HelpViewUseCase()

        // Act
        let result = useCase.getHelpViewController()

        // Assert
        XCTAssertTrue(
            result is HelpViewController,
            "Expected a HelpViewController, but was a \(type(of: result))"
        )
    }
}

I added a message to the XCTAssertTrue because if it fails, I want to know more than "this wasn't true." I want to know why. So I have the message state the expectation, and the actual type. Try breaking the production code by returning the wrong type of view controller to see what the message looks like. (When writing a test, it's important to make it fail somehow to check that it's working, and if a failure gives enough information.)

Your second example is really a separate question, and shouldn't be lumped in with the other question. Feel free to message me directly.

I've written a book that should help you get started with unit testing in Swift. See my profile for details.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文