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.

开云体育

Not what you asked, but when I was writing two (relatively simple) front ends in Elm, I deliberately didn’t write tests, relied on the compiler. I was disappointed in the results, as I found more problems after I was “done” than I’m used to. Most of them seemed to be faults of omission - “code not complex enough for the problem”. In theory, TDD isn’t about those, so shouldn’t cause me to realize them more quickly. In practice, it seems to, for me.

I worked a little on a Haskell project, mainly as a product owner and writing some tests for untested code. Not enough to have any conclusions, except that Haskell is a really nice language for writing tabular-style tests because of (1) relative lack of parentheses, (2) infix two-argument functions using backticks, and (3) precedence rules that didn’t seem to work against me. I forget the details, but I had a number of tests like:

f 1 2 3 `gives` 5

(Maybe that would require parens?)

Elixir is OK for tabular tests because of the pipe operator, but it’s not as good:

?

开云体育

开云体育

The in solution 'framework' that has evolved for these tests does have a bit of a system test feel to it, although it is being leant on to test drive new classes with new behaviours.
Here's an example in pseudo code in case it helps:

[Fact]
public async Task ExampleFact()
{
? await TestScenario

? ? .Given(builder => builder

? ? ? .UserCreatesEntityA("Entity A")

? ? ? .UserCreatesEntityB("Entity B",?new[]?{?new DetailForB { Name = "Detail B"},?})
? ? ? .SystemCreatesEntityC()
? ? ? .SystemActsOnAAndBAndC()
? ? .When(builder =>
? ? ? builder.ExerciseNewUnitUnderTest())
? ? .Then(results =>
? ? {
? ? ? // use results to assert
? ? });
}

开云体育

I am currently working on what you could categorise as a workflow automation product.

The product is comprised of independently deployed front and back end components.

The core domain is realised by a single .Net Core solution.? The front end interacts with it via a REST API and it interacts with further components (and occasionally itself) using messaging.

Two core aspects of the internal design are Entity Framework for data access and extensive use of the mediator pattern.

Using mediator, every element of the solution is broken down into sets of 3 classes, request, handler and result.? Requests and results are POCOs whilst handlers implement behaviour and require few dependencies. ?Often, in cases where the only job to do is orchestrate the sending and receiving of requests and results, the sole dependency is the mediator type itself.? Other requests fall into the two categories of query or command.

All told a well thought out and pleasant stack to work in.? Mediator leads to few dependencies, which in turn leads to simple classes that are easy to drive with tests.

Except for the fact that nothing is ever quite as simple as one would like.

There is a problem writing tests in this solution in that to test a simple isolated query the test setup must replay all the steps the application would theoretically take in order to reach the point whereby the query can return sensible results when issued against Entity Framework over an in memory database.

This is achieved by gathering and then issuing a collection of steps, where each step is a high-level mediator message, as the “Given”s and “When”s of a test scenario.? During the “Then” assertions are made against the result POCOs that were observed by a stub implementation of the mediator type, e.g. assert that the last created entity of type “A” should have such and such an “A.Name”.

I believe the goal of the approach is to use the real application code to avoid making assumptions about the state of the system when writing tests, however the more steps required to reach a the prerequisite snapshot of state, the greater the reliance on developers writing new tests to comprehend the set of steps that should be replayed in order to reach the point from which they want to proceed.

It feels to me as though what has gone wrong here is that although the application code has a nicely decoupled architecture the database and/or the Entity Framework domain model layer does not and as a result entities depend on other entities in a way that makes them intrinsically co-dependent.? This interdependency is revealed by tests which cannot drive simple code without themselves being complicated.

I thought perhaps I could lean on the experience in this group to gain some suggestions on how to reduce this kind of test friction?

Paul

I think this talk is a great place to understand how Justin approaches mocks and TDD:

His style though is an iteration on the London-school approach that's sufficiently different that he separates it in his discussion of the different approaches on that wiki:

Note that the context here is not greenfield TDD but bringing existing code that starts entirely without tests into testing and refactoring along the way initially via characterization tests etc.? The comment above should not be read without that background context as it could otherwise be potentially misleading.? -- Given you start with code without tests there's going?to be some tests being written after the fact, though then even still, you could argue that you could/one should start TDD'ing at the point where you have your characterisation tests and start refactoring towards a new object (say), which if done in that way, would mean you should not then end having to further write "symemetrical" unit tests after the fact.? Perhaps that was your point and I'm just slow catching on.? Still, for the benefit of others just mentioning the context as I initially read this and got slightly the wrong idea without that context.?

I don't actually think this is what he's saying here. He's describing a situation in which a class has been developed with TDD, and has good coverage, but it's growing too large and taken on too many responsibilities. In the "refactor" step of TDD, the solution to this problem is to extract a class that is responsible for one of those responsibilities.

Whereas I'd probably be comfortable treating this extracted class (he calls it a "child", at the risk of terminology colliding with inheritance) as an implementation detail of the "parent", and not writing a unit test for it, he seems to take it as axiomatic that it requires its own "symmetrical" test. (Exactly what he means by symmetrical is documented at?. That wiki is a whole other source of interesting reading.) This is why that section is called "Characterization Tests of Greenfield Code" - because the child class has not itself been developed by TDD.

Having said that I wouldn't immediately bother writing a dedicated test for the child, I think you really see the value of his approach when the child develops a second client, (or more) and then a behaviour change is required in the behaviour of that child. If the behaviour of the child is tested through its clients, then each test of those clients that depends on that behaviour is going to need modifying, which is drudgery. If, by contrast, you write a test at the level of the coordination between the child and its clients, then they don't need to be affected by the change in the child's behaviour. This approach, however, obviously depends on the child's real functionality being covered by its own test.