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 < k...@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 > > > On 22 Nov 2024, at 23:10, Yanni Chiu <yannix...@gmail.com> wrote: > > > > 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 > > <k...@all-objects-all-the-time.st> wrote: > >> > >> Dear Pharo users and developers, > >> > >> I wrote a blog post in which I evaluate SUnit. > >> > >> Enjoy reading it! > >> > >> Ciao, > >> Koen > >> >
