This helper is installable with SPM, see GitHub repo

I’ve been using the Swift Testing framework more. Despite my previous grumble I do like the arguments: feature of the @Test macro and how much it can clean up tests:

@Test(arguments: [
	(true, "bob", 38),
	(false, "sue", 45)
])
func testUserPermissions(isBasketEmpty: Bool, username: String, age: Int) {
    #expect( ... )
}

The ability to supply a list of parameter variants to test is very useful. I think it tends to result in more exhaustive tests because of ease of use.

But being able to easily whack in a list of argument variants soon reveals a slight annoyance. It’s not unusual to end up with a test like this:

I took the new Swift Testing framework out for a spin and used it seriously on a small project.

Conclusion: to me, Swift Testing isn’t ready for serious production use, because either it’s buggy in some important ways, or Apple’s documentation is not specific enough about Testing’s design philosophy and how you should (or should not) use certain features.

My time ratio for “writing tests” to “work out why Testing is crashing” is 1:2 (or worse) at this point.

Testing tools should be well understood and well presented; we trust them with a lot. I think if issues are found with a new framework like Testing, this should be mentioned in the framework documentation.¹

Currying. It’s one of the stalwarts of functional programming.

Is Currying something you need to know about to be a developer?

Nope.

Is it handy to know about?

Yes. Think of it as a pattern for your toolbox. It can allow some elegant solutions and less code.

Is it weird and esoteric?

No; there’s a certain ‘shape’ to currying code but once you recognise it, there’s no mystery.