Do I know anyone who does TDD in a pretty religious way? The benefits and reasons you would do TDD make sense to me abstractly, but figuring out the interfaces and whatnot without writing any code from the outside in is a little hard for me to get my my head around.
Today’s adventure is bugs from a quick iteration on an app that had no tests and would have taken longer to refactor for tests than to ship a build. Sigh.
Should have known better going from strict ASCII path/filenames -> mixed direction text (bidi) ones. Planning on breaking out a small package to make standalone testing easier.
@deirdresm@bgannin@collin Deirdre offers a tried-and-true technique: If it's too hard to test the large thing, break out a smaller thing.
Collin, I've been practicing TDD in Apple-land for 2 decades. Like @GeePawHill I teach it, and coach it. What questions do you have, what challenges do you face? Ask away.
@qcoding@deirdresm@bgannin@GeePawHill Hm. I think I have multiple issues. With testing Apple apps in general, the framework/tooling is missing some kind of basic features that make writing tests a drag. With TDD specifically, it's difficult because apps tend to have the most code at the UI level, and I'm not even sure how I'd begin designing a test for that before I wrote the code.
@collin@qcoding@deirdresm@bgannin First, a little validation: Yeah, frameworks that weren't written to be TDD-friendly are nearly always very TDD-unfriendly.
Second, a little more validation: That's a real and good and hard problem.
Third, I can only be abstract and metaphorical here, cuz neither apps nor apple are a specialty of mine. But in the desktop UI world, the trick is to make "dynamic UI" depend on "dynamic Model" in super-trusted ways, then focus the tests on whether or not "dynamic Model" changes or not. In particular, generic advice: avoid view-on-view violence.
@collin@deirdresm@bgannin@GeePawHill While "stay away from the UI" is often sound advice, there is much about Apple UI that is inherently testable. That's because AppKit and UIKit were born out of NeXTStep, a cousin of Smalltalk. You just have to learn a few tricks, which I share in my book (but will have to write separately about SwiftUI). That said… (1/2)
@collin for a long time, I reverse TDD'd everything. As in "write a manually tested version, comment everything out, only reactivate things to make specs pass". Helped me find quite a few edge-cases.
For refactoring and slight extending, I use the "99 bottles of OOP" approach.
Currently, I try to write smaller spike/POCs, write one huge integration spec for it and then build around that pure TDD Legos, as I understand the goal better.
@kronn@collin Same. I call this “test second development:” sketch it out first, haggle over the structure, get it more or less working and making sense — the. pull that code out and reintroduce it piece by piece using strict TDD. I use it when (1) reliability is critical or (2) interface will be widely used (e.g. designing a library).
I find this approach leads to far better design than strictly writing tests first. Implementation reveals edge cases, reveals tradeoffs, clarifies intent!
@collin related to that: Many years ago someone told me that's hacking (in the bad sense). Over the years I think it's true. And unfortunately I see myself writing code a bit too soon before I think abit more about design, architecture etc. Kind of hammering things into place. That sculpturing process is still really useful, but for me, it has come too early in the process.
@collin I do my best not to be, like, dogmatic about it, but it is a calming and necessary ritual.
It depends a lot on the problem but I often start outside-in. Sometimes to the point of writing a series of relatively slow integration tests to start with, and then later moving the logic in those tests into smaller faster tests once I start to decompose the problem.
@collin Remember that you aren't trying to get everything right from the beginning. You're just trying to come up with a path forward so that then you can use your tests as feedback if your interface is good. Once you've got something down, then you can iterate on it to figure out the interface.
Add comment