Using Custom Assertions to Write Better Unit Tests
updated about 1 year ago; latest suggestion about 1 year ago
This proposal has been withdrawn...
Keeping your unit, integration and application tests as readable as possible is vital, especially when it comes to fixing issues quickly. In this talk you will see how you can write and structure custom assertions to make your tests as readable as possible.
Whatever sort of test methodology you believe in, whatever sort of tests you're writing, at some point you'll need to make an assertion. An assertion allows us to validate what has actually happened in the test. Apple's
XCTest provides us with a large number of basic assertions, but what should we do if we want to validate more complex behaviour?
We could allow our tests to contain multiple assertions, or we could manually extract the specific data we want to assert against, but each of these methods risks damaging the ability of future engineers to easily read and understand the tests.
In this talk we'll explore the problem of test readability, and look at using custom assertions as a potential solution. We'll see how custom assertions, written properly, can improve the readability of tests while simultaneously reducing the amount of code required to write them.
Who's it aimed at?
Developers of any level who have written tests for their code.
Why is my proposal marked as withdrawn? Has it been rejected? I still seem to have the option to withdraw it. Anyone able to explain?
I remember writing fancy assertions for a testing library I used prior to XCTest and it was super. We could test things like
XCTAssertPlayerLoggedIn(player)(using the new XCTAssert style, because I've forgotten what the actual library was).
If I ever wrote tests (I know), it would be nice to be able to write some custom assertions like that again. I suspect those who actually do test, might also benefit from it.