Le 22 févr. 2021 à 00:53, J. B. Rainsberger <me@...> a écrit?:

?

On Sat, Feb 20, 2021 at 1:12 PM Gregory Salvan <apieum@...> wrote:

I never want test doubles, but I also rarely want end-to-end tests. Of course, there are no "stubs" in FP, but merely functions that return hardcoded values.

How do you test your edges ? your monads ?

I don't write monads yet, at least not intentionally. I presume that if I write them, then I use the equivalent of stubs, except that they aren't really stubs, but rather just functions as parameters. I treat them in my mind like OOP interfaces.

As for edges, I presume you mean the point of integration with something outside of the system? I write Learning Tests for the thing outside the system, which are usually integrated tests, and then at the point of integration I choose whether to integrate with the real thing or with a function that invokes the real thing.

--

J. B. (Joe) Rainsberger :: ?:: ::

--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002

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
----------------------------------------------------------------------

On Feb 14, 2021, at 9:46 AM, david@... wrote:

Hello folks,

I just came across this - thanks JB. ?Since the best TDD minds in the Universe are here maybe I can get some help learning...

?

My area of study these last few months has been Swift for iOS Apps. ?I've written lots of example code - but that only takes your learning so far (and it's not far enough!) - so I ventured beyond tutorials and wrote an App for some colleagues and published in the Apple Store. ?Now that required lots of learning that is not in the tutorials. See InspireMe! Cards - Real Advice for Agilists?

I wrote that App without any automated test. ?Decided that was NOT the way to go in the future. ?So I needed to dust off the old Java TDD skills and apply to Swift.

Xcode has wonderful integration for unit testing & even UI testing & performance testing.

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.

I was invited to and jumped at that opportunity - he's a rock star in the TDD community and I highly recommend his awesome TDD course. ?Even if you are NOT an embedded C/C++ programmer you will learn lots from James. ?And to get a glimpse at his work flow - well it is MIND-BLOWING. ?Do not think you know what TDD is until you've seen a master in action... to generalize; YOU are taking WAY to BIG of a STEP!

To solve this problem - I teamed up with the good folks at TDD.Academy and Lance Kind. ?He's mentoring me in TDD on Swift UI with iOS App dev on his Live Coding Stream TDD.Academy ?- shameless plug: ?

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 ?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 you are invited to come along with me.