|
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...
?
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.
|
On Sun, Feb 14, 2021 at 3:08 PM < 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 - 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 - 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 ?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.
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.
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 :: ?:: ::
-- J. B. (Joe) Rainsberger :: :: :: Teaching evolutionary design and TDD since 2002
|
JB> I'm assuming, by the way, that writing automated view implementation tests in Swift sucks. It usually does.
Oh - what would give you that impression? ?But of course you are right!
We did find an alternative to the SUC ... View Inspector library is a nice addition to your McSwifty toolbox.
It's really great... still has some rough spots ... like testing into/thru toolbars.
JB > Do you do anything like this? Would you?
oh yes, I'm constantly opening example/learning projects... here's a portion of my Development folder - of all these project only about 3-5 are For?Realz.
And in the Apple Eco-System there is a PlayGround feature for quickly testing out ideas,...
I don't typically TDD my experiments - unless I'm trying to learn how to best test-drive the experiment...
Xcode also offers a feature - Canvas - which is ... incremental real time compling of the UI code and display. ?It gives you a great idea of the look N feel of your SwiftUI... I'm carrying on an internal debate over if it can replace TDD of the View layer. ?I'm conflicted - between the safety of good test. ?And the ease of design of the UI. ?And the ever present... TDD of UI is freq very HARD.
|
David,
Welcome to iOS TDD! For iOS with Swift and ordinary UIKit, there's my site and book.
But ahh, SwiftUI. (For those outside of Apple-land: this is a complete redo of the UI layer. UIKit is based on NeXTSTEP. Old, hardy, imperative. The new kid on the block, SwiftUI, is ?declarative, brand-new, and still evolving.)
Glad you found View Inspector. As a third-party open-source tool trying to keep up with SwiftUI, there are bound to be gaps. When you hit such a gap, I'd take the easy way out: punt. Basically, extract testable code (perhaps into some kind of view model). Then have the untestable portion of SwiftUI call the testable code.
I'm now following you on Twitch and will join when I can.
- Jon
 |
JON REID / Quality Coding, Inc.
|
toggle quoted message
Show quoted text
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.
|
An interesting exchange. Thanks.
I'm still wondering what it would take the majors, with all the money in the world, to invest in making their systems testable...
S
?
|
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 ----------------------------------------------------------------------
|
Thanks for the words of wisdom on view layer testing. While I understand - I cannot imagine how to extract from the McSwifty code a view model. An example might help.
David Koontz
Email: david@...
(360) 259-8380
toggle quoted message
Show quoted text
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
----------------------------------------------------------------------
|
So cool to see this. I do TDD on Andriod for a while now, and I am curious to see it on iOS. I haven't touched swift/ios development so far, so I guess it will be a nice learning opportunity. Let's see how it goes. Thanks for sharing
|
An interesting exchange. Thanks.
I'm still wondering what it would take the majors, with all the money in the world, to invest in making their systems testable...
Significantly less cash slack. But then in that case, they wouldn't be the majors. -- J. B. (Joe) Rainsberger :: ?:: ::
-- J. B. (Joe) Rainsberger :: :: :: Teaching evolutionary design and TDD since 2002
|
Less cash or less users?
I've assumed that when you have >10 million people using your products every hour, you can rollout to 1% and get faster results than running tests locally.
On Fri, 19 Feb 2021, 10:53 J. B. Rainsberger, < me@...> wrote: An interesting exchange. Thanks.
I'm still wondering what it would take the majors, with all the money in the world, to invest in making their systems testable...
Significantly less cash slack. But then in that case, they wouldn't be the majors. -- J. B. (Joe) Rainsberger :: ?:: ::
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
|
I've Learned how to TDD the LEGACY out of my code - with help from Lancer Kind & TDD.Academy. ?You can watch Lance walk me thru this process on Twitch.TV.Tdd.Academy??Episode 16. iOS Reverse TDD.
Lancer's process is to comment out the legacy code in a method. ?Then write a test that makes you uncomment just a bit of that method's code... write another test... uncomment... test...uncomment. ?Reverse TDD he calls it.
He also showed me how to test a randomCard method... which I had a test that worked about 52 out of 53 times.... a bit of a flaky test.
OK ... he may have lost me as he wanted to make annonous classes inside of functions inside of test - that were partial mocks... of classes... Mind-Blown for a simple PIG.
|
If they had less cash, then they'd feel more pressure to make their systems more valuable. That could mean less in sales or less in investment that compensates for lower sales.
On Fri, Feb 19, 2021 at 9:48 AM Avi Kessner < akessner@...> wrote: Less cash or less users?
I've assumed that when you have >10 million people using your products every hour, you can rollout to 1% and get faster results than running tests locally.
On Fri, 19 Feb 2021, 10:53 J. B. Rainsberger, < me@...> wrote: An interesting exchange. Thanks.
I'm still wondering what it would take the majors, with all the money in the world, to invest in making their systems testable...
Significantly less cash slack. But then in that case, they wouldn't be the majors. -- J. B. (Joe) Rainsberger :: ?:: ::
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
-- J. B. (Joe) Rainsberger :: ?:: ::
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
|
On Sat, Feb 20, 2021 at 3:59 PM David Koontz < david@...> wrote: [Edited Message Follows]
I've Learned how to TDD the LEGACY out of my code - with help from Lancer Kind & TDD.Academy.? You can watch Lance walk me thru this process on Twitch.TV.Tdd.Academy??Episode 16. iOS Reverse TDD.
Lancer's process is to comment out the legacy code in a method.? Then write a test that makes you uncomment just a bit of that method's code... write another test... uncomment... test...uncomment.? Reverse TDD he calls it.
Odd name, but neat technique. It seems like it's "test-first reprogramming" where you're constrained that you can't change the design. Systematic path-level coverage. Nice. OK ... he may have lost me as he wanted to make annonous classes inside of functions inside of test - that were partial mocks... of classes... Mind-Blown for a simple PIG.
Java lets you write function-scoped classes. I use this exact technique in Surviving Legacy Code: the Subclass to Test technique involves writing hand-rolling partial test doubles, so that you discover which parts of the class you want to test and which parts you need to simulate, then you see exactly where to split things apart. It's the coding technique in the course that participants have the hardest time understanding. -- J. B. (Joe) Rainsberger :: ?:: ::
-- J. B. (Joe) Rainsberger :: :: :: Teaching evolutionary design and TDD since 2002
|
I think Lance's technique was fairly easy to follow - I admit to going back and watching the video a few times and playing with the code as I did. ?I even ventured off on my own and wrote a partial mock of the Dictionary shuffle method.
I believe Lance wanted to hide the partial mock inside the test method and was confusing Java & Swift tech. ?Swift does NOT allow anonymous classes. ?But I don't see much gained by the anonymous vs declared inner class. ?We got it hidden - that was an interesting feature to me... ?Scope control and method hiding - WOW!
?
I think there may be room within the technique for design changes... perhaps not in our simple case of the random function... ?but I'd imagine a complex function being re-discovered Reverse TDD style one test at a time... one may choose to add different code that just a simple uncomment a line... I'd foresee an ability to improve the design - the second time is a charm.
We plan to do more Reverse TDD on Friday?
|
One thing I did this last week - thought I could share with you all...?
iOS Dev Happy Hour - Sat - about 300-400 devs in one big Zoom call with breakout rooms to get to know 6, 7 random devs that have experience to share.
|
Last week - I saw someone on twitter mention using Swift Enum to encapsulate Views... so I thought I'd TDD there technique... here's were I got to:
|
David Koontz
J. B. Rainsberger
Jovche Mitrejchevski