Closed davdroman closed 9 months ago
@davdroman Thanks for sharing your opinion.
Our main intention is readability and this approach is more in line with data-driven testing methodology (https://en.wikipedia.org/wiki/Data-driven_testing).
So with a different test method for each input argument is better because, in case of failure, it is easier to discover the failing scenario, assuming you have meaningful names.
Maybe for such a simple case as in readme, it doesn't make sense to use it. But we believe can be useful for more complex scenarios.
@Parametrize(input: ["001",
"002",
"003"],
output: [("Saving Account", NSDecimalNumber(string: "3000")),
("Kredit Account", NSDecimalNumber(string: "-15000")),
("Basic Account", NSDecimalNumber(string: "2345"))],
labels: ["SavingAccount",
"KreditAccount",
"BasicAccount"])
func testAccountViewModel(input accountId: String,
output expected: (String, NSDecimalNumber)) throws {
let viewModel = AccountViewModel(accountService: accountServiceMock,
accountId: accountId)
XCTAssertTrue(viewModel.isLoading)
let expectation = expectation(description: "refresh call")
viewModel.refresh {
expectation.fulfill()
}
wait(for: [expectation])
XCTAssertFalse(viewModel.isLoading)
XCTAssertEqual(viewModel.accountName, expected.0)
XCTAssertEqual(viewModel.balance, expected.1)
}
But we are open to any suggestions to make this macro more helpful.
Oh yeah I can see how that simplifies things. Thanks for illustrating! 👍
Not trying to bash this effort, I'm just curious about this library's angle.
How is this:
... different from:
... besides the splitting into individual test functions?
Is there an aspect of unit testing that's hard to do with
for
loops but this library makes substantially easier via@Parametrize
?