So a given web application has an architecture which involves a UI and an API and under that some domain objects, data, etc.
When a new feature comes up, there is a gherkin test that does NOT go through selenium, but directly to the API. In developing the gherkin test, the team drives out the changes needed by the API and gets it working.
The gherkin test is a "story test" and checks to see if the system (behind the UI) works correctly. It does data, persistence, etc in a safe way.
But to build the code, you are doing TDD directly on the API and the deeper domain objects. As you do, you are refactoring and committing (of course).
The microtests and the gherkin tests together are super-fast, so you run both kinds many times per minute. You're always clear where you stand.
But of course, there is a web page to deal with. You create render tests that will turn data (specifically the kind needed or returned by the API) into a web page.

Now, these are back-end rendered old-school style.

But you get that working correctly. Is it ugly/awful? Sigh.
Okay, you fire up the web server and look at the page, and sure it's ugly. You work on the CSS and make it look better. You're using a development web server that reloads the page when the HTML or CSS change so it is fairly quick if tedious.
But where is your automated test to be sure the wiring between the web page and the API is working correctly?

Okay, you write some selenium tests. Just the necessary ones, maybe just automating tests you were doing by hand to check out the web page(s) rendering(s).
Hey, the app works! You deploy.

Move on to the next feature.
Your friend mentions that some of the code exercised and checked by the UI test is also checked by other tests.

The render tests check the DOM
The API tests check message-passing
The microtests check underlying functions
The UI tests are end-to-end
Your friend says "this is inefficient, because the same code is getting coverage more than once."
You smile. You know it's not inefficient, because you aren't measuring efficiency by total lines written or the number of times you 'had to' run the tests, or by a standard of minimal coverage.
You know that human efficiency is high - it's a quick, reliable, and safe way to create a system that can be safely refactored, extended, modified.

But how do you explain that to your friend?

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Agile Otter Tim

Agile Otter Tim Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @tottinge

14 Sep
Primitive Obsession Detection:

when you see:
<primitive type> variablename;

See what methods the primitive type has which are not appropriate for the domain of variablename. What does type do that variable shouldn't?
string CustomerId;

What does string do that a customer ID shouldn't?
It can be
* passed as a time zone.
* upper/lower cased.
* concatenated to/with other strings
* passed as a filename to open()
* centered in a field of spaces
* used as a format in a print statement
* searched
int typeCode;

It can be:
* operated upon bitwise
* used as a port number
* treated as a boolean
* multiplied/divided/added/subtracted
* overflow/underflow
* passed to so many functions!!!
Read 7 tweets
3 Sep
Q: Why say "ensemble"? Just use the proper name "Mob Programming!" Is this just PC run amok?

A: I needed a term to encompass Pair Programming, Mob Programming, and Swarming. That it's inoffensive is a very nice and welcome bonus (worth it).
You know, people snigger when I say "pairing" as shorthand for pair-programming. It suggests sexual behaviors.

People also flinch when I say 'mobbing' because it is a term for grouping up to bully people in schools and workplaces.

"Grooming" is another - suggesting pedophilia.
We deal with words as they are used and try to not draw connotations we don't mean. That's just being clear.

"Ensemble" is a good category term. The other, better, term is "teamwork" but people have coopted that to mean all kinds of "working near but not together."
Read 8 tweets
1 Sep
Just read a story about a new COO who started their first day on the job by cleaning the kitchen.
They drew a line saying that " spread the word that the next person I caught leaving a mess for their fellow employees to clean up would be shown the door."
Leaving a mess for their colleagues to clean up?
Sounds like Business As Usual in a lot of corporate software groups.
"If I don't do a good job, then that's okay. I can close the ticket and someone else will fix it."
Because, sadly, in many shops "getting things done" is "closing tickets."

"Look how much we did! We closed 20 tickets!"
"What can we demo today?"
"Well, nothing. It doesn't work yet and we can't deliver, but 20 tickets!"
"That's fine, then. Next sprint, we want 30 tickets."
Read 11 tweets
10 Aug
Why don't you have tests?
Why don't you refactor?
Why is the code so bad?
Why can't we be responsive?
Why are we slowing down so much, so fast?
The problem with sprint packing (maximum amount of work per time box) is that people have to cut corners (including quality, design, testing) to make a tight deadline -- only to be given one equally tight or tighter.

Ad infinitum.
The kind of "go faster" that teams do to keep up with the work is like the driver ignoring warning lights, not getting tires changed, not washing the outside or throwing away trash.

It's an ugliness that piles up because there isn't time for caretaking.
Read 7 tweets
12 Jan
People often treat standardization as a self-evident good.
They want everyone to do everything the same way so it will be standard.
A short thread is in order here.
The primary reason we standardize things is for interoperability.

If we're not going to interoperate, then there's no point in standardizing.

If we ARE going to interoperate, then we need standard *interfaces* not standard everything.
This suggests that we don't need everyone on every team to work the same way, or for teams to operate (internally) the same way other teams interoperate.
Read 12 tweets
8 Dec 20
The most brilliant programmers alive working competitively in an ego-rich environment can’t get as much done as ordinary programmers working cooperatively as a self disciplined and self-organizing team. You need a process where team empowerment and collaboration thrive.
I'm very sorry that this quote didn't show up with quotations and a link. It should have. I'm not sure where it came from now.

This saddens me. I hope it's not lost.
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(