Prior to 1972, was there any automated unit-testing? Did any assemblers include a testing a framework?
I can find some academic journals on this topic from the late 70s -- most of which I don't have access too, but I don't see any implementations or examples of it. What providers pushed automated unit testing? Did automated software unit testing start with tooling for C or are there prior examples?
Update: Computers in Spaceflight: The NASA Experience confirms that unit testing was performed on the Apollo software:
The simulations followed individual unit tests and integrated tests of portions of the software. At first, MIT left these tests to the programmers to be done on an informal basis. It was very difficult at first to get the Instrumentation Laboratory to supply test plans to NASA. [...] NASA exerted some pressure on MIT to be more consistent in testing, and it eventually adopted a four-level test structure based largely on the verification of the Gemini Mission Control Center developed by IBM in 1964. This is important because formal release of the program for rope manufacture was dependent on the digital simulations only.
p. 47
At one point Bill Tindall, NASA's overseer of the MIT effort, complained about the lack of unit testing:
On June 13, Tindall reported that the AS-204 program undergoing integrated tests had bugs in every module. Some had not been unit tested prior to being integrated. This was a serious breach of software engineering practice.
p. 50
Tindall's memo is archived here. You can see that he calls it a "unit test" on June 13, 1966:
In fact, some of the programs – the 30 and 40 series – have not even been unit tested, although they have been included in the program assembly currently being used for system tests. This is certainly a very unsatisfactory situation.
The command modules and lunar modules of the Apollo space program were each controlled by the same model of guidance computer. It was the first computer built from integrated circuits (NOR gates).
The software for the AGC was written by a team led by Margaret Hamilton at the Draper Laboratory of MIT. It was written in assembly language, with an assembler written by the Draper team.
Hamilton was particularly concerned about how software handled errors. At the time, errors were often dismissed as "bugs". Hamilton knew that this was not acceptable for the Apollo software, not only because the executable code was hand-woven into core memory – making changes difficult – but also because the lives of the astronauts were at stake.
Individual sections of the software were tested as they were written. Special tests were made on the running code:
Executable tests may have first been introduced by Margaret Hamilton on the Apollo project in the mid-1960s, where she originated a type of executable checking that we now call “static code analysis.” She called it “higher-order software,” by which she meant software that operates against other software rather than directly against the problem domain. Her higher-order software examined source code to look for patterns that were known to lead to integration issues.
https://www.leadingagile.com/2018/10/unit-testing-shell-scriptspart-one/
Hamilton named their method "software engineering". She later formalized it, wrote over 130 papers, and started several companies specializing in software engineering.
In 1986 she began her current company Hamilton Technologies. At Hamilton Technologies projects focus on work Hamilton began while at MIT including a Universal Language System. This system develops software off the theory “Development Before the Fact.” It focuses on the function and timing of data within a system to prevent errors before they occur. The automation of this system created the 001 Tool Suite (pronounced double-oh-one), an updated version of the work Hamilton began in her first company. The 001 Tool Suite is used to develop automatic software code and simulations.
In 2016, Hamilton received the highest civilian honor in the U.S. – the Presidential Medal of Freedom – for her groundbreaking work in software engineering.
Was there any Unit-Testing prior to 1972?
Yes there was. Only a fool would put a system together out of untested and undebugged parts and then try to make the system work. No framework is needed: you write some code, you test it in isolation: that's unit testing by original definition. Now you can combine your units into the next level of thing.
In the mid-1970s (ok, not before 1972, but the art doesn't change that quickly) I wrote a PDP-11 driver for a synchronous communication device, which I debugged by wrapping it in some code that simulated at some level the operation of the hardware. That's a unit test. The driver basically worked by the time it saw real hardware. The test structure got thrown away (well, packed into my bag of useful pieces) once the driver worked; from that point it was tested in use.
You may be confusing "automated unit testing" with "unit testing".
Prior to the creation of C, was there any unit-testing? Did any assemblers include a testing a framework?
Erm. There is no specific relation between C and testing. C as a language doesn't feature any mechanics for (unit) testing. Testing was and is a distinct item in its own right. Like for many other components of development, more generic tools and procedures have been developed and provided. Nowadays often seen as natural parts of a language, as the are presented in an integrated way - hence the common name Integrated Development Environment - but they are only made to look that way, they are still just sold as a package.
Of course, there are languages that naturally ease some aspect of automated testing - usually as side effect due the formal way of specification they employ to reduce undesired effects. The same information can be used seamless for certain parts of verification and test automation. I'm for one a great fan of Ada (*1). Its way of clear defined data and operations thereon allows not only detection of unsafe or faulty constructs during compilation, but as well on demand addition of test.
Another great example is VHDL, as here the definition of a test bench is (almost) mandatory and part of the language. So while a test framework is part of VHDL, it also shows that any framework (beyond simple, formal checking), goes beyond what a language can do and is always application based.
I can find some academic journals on this topic -- most of which I don't have access too, but I don't see any implementations or examples of it.
Because testing always has been and forever will be a domain of application specific tests. While some languages are (or have developed to be) supportive of test scenarios, it's the application environment that defines the how and wherewith. This is the same way true for unit tests as complete runs.
Thus tests are not only language independent, but also technology independent. Testing goes goes back into the age of mechanical punch card operation. I remember porting an application from stand alone (batch) /370 Assembly, operating on punch cards to a disk based environment (as well /370 Assembly - but we finally got red of all the highly opaque manual/scripted batch). These were the early 1980s. One fun part was that this batch application itself has been converted some 10+ years before from mechanical punch card to /360 Assembly.
Among the documentation I found a set of card stacks, various plug sheets a one special page: the test bench for the run. It was a rather complex setup with several plug sheets involved and multiple tabulator runs. Whenever it was set up for production these stacks were feed to the tabulators to produce an output stack. This output stack, and one of the test stacks was then to be fed to a collator plugged (the collator plug schematic was part of the documentation) to compare both stacks. The documentation stated that this had to be done before each and every run were the machines have been used otherwise inbetween.
Long story short: Test benches have always been a thing and there has been automated support even in the dark ages of mechanical computing. The difference is like with all our too in vastly grown resources that allow more support than ever before.
*1 - Yes, Ada and Assembler do get well together in my mind, as both allow almost unlimited freedom in design. One just needs to specify what is intended. In the end they only differ that in Assembly one can talk dirty without coming clean, while in Ada everything has to be spelled out in a calm and polite manner :))
