The blog post has "Nobody thought about automating that process. Until
Kent Beck did." That is not accurate, AFAIK. I believe it was in Kent
Beck's original EXtreme Programming book where he says the practices
were gathered from various Smalltalk shops he consulted at during the
Smalltalk heyday in the early 90's.

For what it's worth, here's the history I know. Around 1993, in
Toronto, I was working at Footprint Software on VisualBanker (a suite
of code to support banking that 4 of the 5 major Canadian banks
bought). With my programming buddy (no "pair programming" at the time)
our task was to build a persistence framework (supporting Relational,
ObjectFiler, and in-memory).

My task in a previous job was to convert (the AT&T Unix) C compiler to
support the "new" ANSI C standard. Thankfully, I was provided with a
test suite of C code, so that if it compiled without errors, then the
compiler was standard compliant. So, looking for something similar to
the ANSI C test suite I'd encountered, I set up test cases where all
methods starting with "test" would be run, and ran the tests against
all the backend data stores. The next day, my programming buddy
(George), who started at 6am (to have a faster commute) tells me this
test thing is great, and shows me the UI he built so we could just
push a button. We can check the same behaviour for all backends, and
we can coordinate our code changes through the tests (to mitigate our
different schedule).

A year later, the company's product was deemed slow, so they
contracted Kent Beck to review our code base. He eventually comes
around to us. We showed him what we did with tests, and then he just
paused for about a minute staring out the window. We thought we were
doing something really bad. A few months later, George said to me "did
you see the SUnit thing posted on comp.lang.smalltalk". The basic
"test"-prefixed test cases were there, but with the addition of the
setUp and tearDown concept.

Every once in a while I think to write this up. The "Nobody thought
about automating..." words pushed me over this time. Maybe 15 years
ago, I was able to find the original comp.lang.smalltalk SUnit
posting, but could not locate it this time when I wanted to verify the
dates.

Yanni Chiu,
Smalltalk oldtimer, Toronto

On Fri, Nov 22, 2024 at 8:58 AM Koen De Hondt
koen@all-objects-all-the-time.st wrote:

Hi Yanni,

Thank you for sharing your story. It gives another view on history. Maybe you should share it with a wider audience.

As always, the people publishing about something for the first time get the credits.

When I wrote "Nobody thought about automating that process. Until Kent Beck did.”, I meant that he was the one who published about SUnit for the first time (and that is why I linked to the publication). I am sure that many other people, like you and George, had tools to automate tests, in one form or another. After all, Smalltalkers build their own tools to automate repetitive tasks. That is a super power Smalltalkers have compared to developers using other programming languages.

You write about 1993. Back then, it was hard to share code/projects/software with the world. These days, people put their code in a public repo. But still that does not prove that the underlying ideas are original. It just proves that they did something creative with those ideas, just like in 1993. But at least it is clear for the rest of the community who is building software based on those ideas.

So I think publishing work – even early work –, in the form of code or written documents, is crucial to keep a trace of where ideas originate.

Thanks again for sharing. I like stories about the history of software development and I enjoyed your story.

Best regards,
Koen

First, automated test running was common practice in software engineering.
We were doing it with shell scripts at my company back in 1985.  And of
course this is precisely what “expect” was written for, and it’s why tools
like tcov/xcov exist for conventionallanguages like C.  SUnit just made it
easy .

Second, why would anyone expect a one to one correspondence between
method names and test method names?  Where is it written that a test case
tests or indeed can test only one method?  Take a trivial example like
testThatAddAdds
|x m|
x := testClass withAll: #(1 2 3 5).
m := x size.
x add: 4.
self assert: x size equals: m+1.
(Typed on a tablet, so pretty rough.  Sorry.)
Does this test #add: or #size?  I’ve known tests like thisto find faults in
#withAll: and in one memorable case #+ .

If you want to document a link to what you’re testing, use a pragma.
<test: #consistency of: #add: with: #size>
and set up your UI to realize that this is a test of BOTH #add: and #size
so that it should be rerun if either of them changes.
On Sat, 23 Nov 2024 at 2:58 AM, Koen De Hondt <
koen@all-objects-all-the-time.st> wrote:

Hi Koen,

I understand that as a writer, something like “Nobody thought about
automating…” does more to draw a reader in to reading more of the article,
than something like “Nobody had ever published a public domain framework
that …”. As your reply says, your intended meaning may be “published … for
the first time”, but I think very few readers would take that meaning. In
my own experience, automated testing was a concept I encountered from
earlier programmers, and Richard’s post also confirms that automated
testing was commonly known.

You’re right about the “open source” environment of the early 90’s.
Employees/programmers were unlikely to publish code into the public domain
at that time. I think Kent was in a unique position to tour various
Smalltalk teams, distill out key processes and techniques, and publish
about it. SUnit is a great distillation of the idea.

The actual unit test framework code is not the key idea. People knew of
using automated test suites. But flipping to another browser and adding a
#testZZZ method, while coding for your development task, is something that
seems to just emerge from the Smalltalk environment - once you determine
that you want to have a test suite to help you code. Previously, some
statically defined test suite, perhaps written by others, is used to verify
code. By putting the #testZZZ definitions in the hands of the developer,
the whole waterfall coding model is upended.

Regards,
Yanni

On Sun, Dec 29, 2024 at 10:44 AM Koen De Hondt <
koen@all-objects-all-the-time.st> wrote:

"statically defined test suite, perhaps written by others" fairly hits it off.
I once had the privilege of supervising a student who was working with
the test suite for a major betting chain.  (No, I'm not going to name
it.)
The official test suite was a Microsoft Word document and he was
trying to extract as much as he could to turn it into scripts.
Too many of the tests had the form "do this, and then look at the
screen", with nothing said about what to expect.
And some absolutely crucial things were not tested at all.  The one
that comes to mind is that every bet had to be remembered for a legal
minimum of five years.

This is one of the areas where sUnit shines, because Smalltalk shines.
You can inject UI events and you can capture UI outputs without
leaving
the single environment.  You use the SAME testing framework for
financial calculations, network interactions, and UI.  So I do think
that sUnit was
innovative, just not for running test suites automatically.

It would be interesting to see a comparison that involved Cucumber.
If you want to talk about tests that the customer can read,
you have to say something about Cucumber.  I note that the big selling
point for COBOL, back in the day, was that it was based on
English so managers would be able to read it.  Hah sarcastic hah.

On Wed, 1 Jan 2025 at 09:16, Yanni Chiu yannix7db@gmail.com wrote:

Thanks for sharing it with us.
It is great!

Stéphane Ducasse
http://stephane.ducasse.free.fr
06 30 93 66 73

"If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.” Calvin & Hobbes