开云体育

On Feb 17, 2021, at 1:42 PM, George Dinwiddie <lists@...> wrote:

?Good advice, JB. I'd like to add a couple tidbits from my experience (not with Swift UI). These are inline, below.

On 2/17/21 6:27 AM, J. B. Rainsberger wrote:
On Sun, Feb 14, 2021 at 3:08 PM <david@... <mailto:david@...>> wrote:
Hello folks,
I just came across this Groups.io - thanks JB. Since the best TDD
minds in the Universe are here maybe I can get some help learning...
Welcome!
A card flipping App doesn't have much business logic nor Obj model -
but has lots of views in the SwiftUI world. So testing the View
layer is the primary need. Trying to learn the UI testing layer
inside of Xcode is very difficult... can't seem to find much
documentation. All the examples of course WORK... but my attempts
do not... so learning from "canned examples" is not fruitful. My primary advice to anyone in this position would be to separate Learning Tests from test-driving behavior in your application. I tend to write my Learning Tests in a separate _project_, the copy/paste my learning.
The flow goes like this:
- Intend to build some UI for feature F
- Do some incremental UI building with "microtesting" by manual inspection
- Something unexpected happens or I can't figure out immediately how to do something
- Switch to my "Learn Swift UI Toolkit" project
- Try to do it there, complete with automated tests, even if they are slow and crappy

My first attempt at learning TDD was a Java2D visualization of some data. Some of my tests were of the form "the screen should show <such-and-such> (Y or N)" which would wait for me to press the Y or N key. Ugly and a bit slow, but faster than alternatives.

- Get a minimal example of what I want working
- Clean up before moving on: write some documentation (just bullet points) of what I've learned while it's fresh

When I'm using microtests to learn an API or library, I try to edit the tests to be readable as that documentation. I've found that to be immensly helpful when a new version comes out and some of what I learned is no longer true.

- George

- Make coffee
- Switch back to my application project
- Do more incremental UI building with manual "microtesting" and see that it now just works
I'm assuming, by the way, that writing automated view implementation tests in Swift sucks. It usually does. If it doesn't, then I rely more on automated tests, but I still do the learning in a separate project where I force myself to understand more clearly what I'm trying to do. That helps me avoid falling into the hole of having something "happen to work" because Their Framework has some Big Dependency that I didn't know about.
Do you do anything like this? Would you? What do you think about it? When I don't do this, I typically regret it eventually.
Yet I've still got many many questions. And I've learned lots in
the last several months. I now consider my self a TDD beninnger and
perhaps competent in SwiftUI Testing... which means I can spend
hours banging my head on a testing of a simple iOS app and fix it
the next day - Competent.
So what have I learned: (maybe this is a good place for a list)
- Doing TDD is way easier with a mentor (programming pair) - I still
forget to write the test first.
- Testing the Zero (NULL) case first
- Using the Empty-Class pattern
- Learning to craw - before I attempt to RUN.
- Tons of Swift & SwiftUI stuff
- SwiftUI toolbars don't play well with the testing ID
accessibilityIdentifier() - so you can quit banging your head on
this one - my head is flat.
- UI tests are NOT fast... 3 orders of magnitude slower than a unit
test.
- You MUST speed this up... so you go get View Inspector
<> and
learn to unit test the View layer.
- Even View Inspector has problems with toolbars... so you go back
to head banging...
- Apple has a big war chest of money - and then are not spending it
on programmer documentation
- You need to know your View hierarchy - so in a test
"print(app.debugDescription)" - is Your savior
- You could try the dev tool - /*Accessibility Inspector*/ - but you
will return to the print statement.
- You have to GROK the XCUI element query stuff... and no one will
talk about it in the examples/tutorials
- You guessed it Apple doesn't understand it so they did not
document XCUI Element Query...
- so something like*app.buttons["my_button"].tap()* might just poke
your buttons
I'm journaling my experiments and learning opportunities on The
Swift Dojo <> you are invited to
come along with me.
Excellent! BTW, please update your front page:

Fridays in November about 5:30pm CT we are going to develop a Baseball App with TDD - you are welcome to join in. Twitch.TV/TDDAcademy <>

I know how easy it is not to notice those things. :)
I want to promote this. What exactly do you want eyeballs on right now? I'll send as many as I can.
--
J. B. (Joe) Rainsberger :: tdd.training <> :: jbrains.ca <> ::
blog.thecodewhisperer.com <>

--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------