Swift Testing influencer: A chance at redemption?

Today could be an interesting day for me. I am going to start using Swift Testing.

Test-Driven Development has occupied an extremely awkward stance in my career. As a young college graduate in 2006, I was swept up in the excitement pervading the Ruby community about code that tests code.

As that environment was thick with theoretical dreamers, there was enough patience to implement such things, and a general consensus that these additional steps would speed up the overall work. It was best of all if you wrote the tests before you implemented the code that made them pass.

Among Rubyists, I considered myself one of the dreamiest of all, so assuredly I opted for RSpec and basically all of the plugins that went along with it. There was not really any chance that I would proceed like

assert(!@elon.shadow_banned?)

when I could do this instead:

@elon.should_not be_shadow_banned

But even that was not enough. I would immediately transcend to the next level of “optimization”, using Cucumber and WebRat and Machinist to automate different steps of the test creation pipeline. These libraries were legitimately amazing, well-documented, and not very buggy. But they accomplished these shortcuts using advanced techniques of Ruby that made it very hard for me to analyze what I was doing wrong during the inevitable guess-and-check period of learning a domain-specific language.

When I got my first job based in NYC, my boss Avi Flombaum (who later founded Flatiron School) was in London for a couple weeks, so I got a dream assignment. Look at the code and add specs. Incredible: I get to take my time before having to implement anything, and I get to learn about my favorite thing while making the system MUCH easier to improve!

The thing about tests and specs that is usually the first stumbling block for newbies trying to emulate examples in the README is that to run them, you usually need to provide ways for them to connect to other layers of your system. Rails had, even from version 1, substantial additions to support this endeavor. But some of them were not nifty enough for my taste, and others were just beyond my comprehension at that point. This assignment didn’t produce any results, and because I gave back my salary for the weeks, it eventually led me into some drama that ended the partnership.

That decade I made dozens of Rails apps, and each time I would get mired in over-engineering the RSpec configuration to the point where I could not use it. Although I was increasingly aware of this irony, I felt I didn’t have enough open source examples of how it was really supposed to be done, to get over the hump and reap the benefits. I began to hide my eyes in shame at Ruby conferences when the discussion got specific, even receiving a tongue-lashing from evangelist par-excellence Obie Fernandez.

When I had an opportunity to work at Pivotal Labs, I did truly get some laps under my belt with testing. In the purest pair-programming fashion, one of us would write the test, make sure it failed, and then pass the keyboard to our partner to hack away until the entire test suite was highlighted in green. That way, you could know that you weren’t breaking one thing as you were fixing another.

This possibility, known as a regression, was only one of the major benefits of TDD. Another was to hold you back from adding too much functionality at a time. And in theory, it was certainly possible to make the tests pass without knowing how the code even worked. A fourth benefit was that the opportunity to read the specs afforded a great deal more clarity about what the code was intended to do — especially useful in Ruby, where the preferred code can alternately resemble Perl, Lisp, Java, or C.

Fast-forward another decade or so and many developers have settled for putting tests in as a much later, and smaller part of their flow. Even Obie took this approach as he founded a string of high-tech businesses, partly because he was writing much of the code by himself. Reflecting now, I wonder if part of the transition was related to how much essential behavior is now achieved through CSS rather than code. While Selenium has been operational since time immemorial, it never got traction, and the snazzier alternatives were probably highly subject to configuration/documentation purgatory.

As this relates to Swift and iOS in general, the testing community in that universe has never been front-and-center. Testing was still possible and advisable, but there were not as many conferences or thought leaders to make it approachable. As Xcode gradually added support for targeted execution, the allure grew, both for time/aggravation saved, and for respectably-stylish color-coded reports.

Then this summer Apple announced Swift Testing, a brand-new framework with, to a first order of approximation, all the expressive bells and whistles that had made RSpec a feast for the eyes. And just in time, I am learning that the many stipulations for how variables and databases are accessed mean that Swift development is only simple in a deceptive sense.

Two days ago I found myself repeating a somewhat arduous loop: ask Cursor for a new idea, save the file and switch to Xcode, clean the build directory, stop the simulator so I could delete the app from its home screen and double-confirm that I also want to remove its data, then launch the app and see if it reaches my breakpoints. Even when it did, I was unsure if the data had been saved. The next morning, Xcode 16 with SwiftTest was ready to install.

If I let my hopes get too high this could absolutely become another wild goose chase. Fortunately, this type of coding may well be one that AI assistants can understand correctly. On that note if you have Rails apps, I’d suggest asking a few AIs to add specs for some of your methods, and if you don’t, start making Rails apps. The DHH interview with ThePrimeagen should be on YouTube by now.