There is a plethora of tools available for engineers to test their code these days. However, frameworks like Mocha.js came around only in 2011 with the ascent of NPM. So I wonder what were the practices around software design a few decades ago?

closed as too broad by gnat, Kilian Foth, Bart van Ingen Schenau, Basile Starynkevitch, Doc Brown Jul 10 '17 at 11:01

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    There were frameworks and tools long before Mocha. E.g. I know that the Perl language came with unit tests in the TAP format in the late 80s, but it hardly was the first. Cyclomatic complexity was developed by McCabe in the mid-70s to enable comprehensive white box testing, but that too builds on older ideas. – amon Jul 10 '17 at 6:44
  • 2
    Run system tests on a complete representative system. If it doesn't work, use a debugger to find the problem. Or roll your own test harnesses - create simple executables that call different bits the code under test. – Simon B Jul 10 '17 at 7:23
  • 3
    19xx is a very vague timeframe, spanning from the beginning of computers (mid-40s) which were programmed by adjusting cables on a big switch board, all the way to "not that different from what we do now" in the 90s. In 1995 CPAN went online, which is to Perl what NPM is to JavaScript. And even test-driven development is from the previous century, even though it reached high visibility only at the beginning of this one. – Sebastian Redl Jul 10 '17 at 8:27
  • 1
    I've seen assert() used as a simple unit test – Nick Keighley Jul 10 '17 at 9:39
  • 1
    What makes you believe testing requires a framework or a tool? Frameworks and tools make testing more efficient, but it is pretty obvious that they are not mandatory. – Doc Brown Jul 10 '17 at 11:03

In the really early days, (mainframe & batch jobs days), testing was accomplished by the systems engineers writing a set of test data that they had hand calculated the results of but only gave a small sub-set of to the programmers. The programmers wrote the code and the test suites were run against the program and the output passed to the systems guys who passed back pass/fail results.

Of course we were also using static analysis tools such as lint, (in Unix from 1979), to spot areas needing specific attention.

A little later, when programmers had direct access to some hardware, we would write your own test harnesses & stubs to test our own code. Some teams had a process whereby developers tested each others code and for some projects where many sub-processes had common interfaces a generic test harness might be implemented to allow standardisation of testing and save the time of every developer creating their own test skeleton for each process, I have done this myself on more than one team.

In the late 19xxs they, we, were were using test frameworks such as LDRA Testbed, (founded 1975) & IBM Rational Test RealTime for safety critical code C.


They had to define some input data, manually calculate the output, and then check it by running the program. See e.g. the paper The FORTRAN Automatic Coding System by Backus et al. (1957):

He then programmed the job in four hours, using 47 FORTRAN statements. These were compiled by the 704 in six minutes, producing about 1000 instructions. He ran the program and found the output incorrect. He studied the output ... and was able to localize his error in a FORTRAN statement he had written. He rewrote the offending statement, recompiled, and found that the resulting program was correct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.