开云体育

Test execution speed is only one negative effect of this overly-tight coupling. In the past, it provided practical motivation to split things apart; now that the speed difference has diminished, we have lost one of the blunt instruments that used to help us nudge programmers towards the benefits of looser coupling.

Coupling always feels comfortable until suddenly and violently it blocks your path. Usually when you _really_ want to change some little thing, then realize that you need to change the same thing in 20 places. And that's even before the code becomes legacy code for you.

That means that this "lesson" becomes even harder to teach, but not much less urgent to learn.

At the same time, 700 ms is pretty slow for a "fast" test. 1,000 such tests takes 11.5 minutes to run, even with 0 startup time.

The trick is to need fewer of these tests, which still leads to isolating technology integration from the domain core _at a minimum_.

J. B. Rainsberger :: :: ::

On Fri., May 13, 2022, 12:38 Avi Kessner, <akessner@...> wrote:

It's interesting to me.?

Today I wrote a test which was confirming the behavior of a queue to write to a DB with the correct changes.

I starting by writing the test in our e2e folder, because I assumed the test would take multiple seconds. However, since we are using docker containers for all the dbs and queue services, I was actually able to remove all my polling loops waiting for data to be updated, and the test looks like a typical unit test, (it's 5 lines long) though it takes 700ms to execute in the IDE.?

I used to be able to distinguish unit/integration/e2e by saying unit all runs in memory, integration involves one network call, and e2e involves multiple network/frontend calls and most closely resembles what an end user would experience.? But now, my faith in such distinctions are fading.

On Fri, 13 May 2022, 17:14 J. B. Rainsberger, <me@...> wrote:

On Fri, Apr 29, 2022 at 12:49 PM Charlie Poole <charliepoole@...> wrote:

?

It's ALL jargon! In the first meaning (in most dictionaries I checked) of "language peculiar to a particular trade profession or group,"

rather than in the sense of something negative or not understood.

Yup. And since human nature is to let meanings wander but keep the words the same, if we want a self-regulating system, then we need some people to nudge us back in the direction of using words that convey more broadly the meanings we wish to convey. I am one of those people. :) I have no illusion about fixing anything, but if I can make it easier for more people to understand us, I'll do that.

The "micro-test" movement has grown rather large, so I think you should critique it (if you want to) by using the definitions that

already exist, not just what the word "sounds like."

Well... "micro" suggests "small" and I happen to know the origin of the term as well as its originators, so I feel pretty confident in clarifying the original intention. :)

?

Now I'll whine too. :-)

Our TDD, XP and Agile movements have been plagued by the search for terms, which everyone will automatically understand

(in the same way we understand them) upon first encountering them. There really are no terms like that. In the rather basic

dictionary I have by my desk, there are 14 definitions of "test" and 13 for "unit." ("Behavior" has only four, which will make some

proponents happy, but they are mostly pretty non-specific and don't include "Category for which Charlie used to get a low

grade on his report card!")

Generally, to understand the "jargon" of a group, you need at least a definition. Sometimes you may need to read an article,

have a conversation or even digest a book or two. While that may sound like a problem, I've never seen it arise within the

actual teams that do the work. Of course, when we get on the internet with people following different usage, we may not

immediately understand one another. I think that's just a fact of life. We should mitigate it by not calling "hot" things "cold"

or "fast" stuff "slow" or "small" tests "big". But non-self-explanatory terms are easily bested by people who work at understanding.

Yup. I have no illusions of success, but I see the value in nudging. Either it helps or it doesn't. We all have different pet projects. I don't mind.

I've encountered a person who believed that "refactor" means "add a feature" and there is much confusion about what "integration test" means. Sometimes big groups come to understand X to mean not X. If I can help reduce that confusion, I'm happy to continue, at least in my spare time.

--

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

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