Jakie jest pierwsze opublikowane odniesienie do programowania w pierwszej kolejności?

Ponownie czytam Refaktoryzację autorstwa Martina Fowlera. W rozdziale 4, Testy budowlane, natrafiłem na następujący fragment.

W rzeczywistości jednym z najbardziej przydatnych czasów do pisania testów jest rozpoczęcie programowania. Gdy musisz dodać funkcję, zacznij od napisania testu. To nie jest tak zacofane, jak się wydaje. Pisząc test, zadajesz sobie pytanie, co należy zrobić, aby dodać funkcję. Pisanie testu koncentruje się również na interfejsie, a nie na implementacji (zawsze jest to dobra rzecz). Oznacza to również, że masz wyraźny punkt, w którym kończysz kodowanie - kiedy test działa.

Chociaż jestem teraz zwolennikiem rozwoju opartego na testach, nie pamiętałem, że zostałem wprowadzony do tej koncepcji, kiedy czytałem tę książkę prawie 5 lat temu.

Według Amazon.com ta książka została pierwotnie wydana 8 lipca 1999 r. Czy to pierwsze opublikowane odniesienie do programowania w pierwszej kolejności, czy jest coś jeszcze wcześniej?

Rozwój oparty na testach jest podobny do projektowania na podstawie umowy, w którym istnieją warunki wstępne, niezmienniki i warunki dodatkowe.

Termin został ukuty przez Bertranda Meyera w związku z jego projektem języka programowania Eiffel i po raz pierwszy opisany w różnych artykułach od 1986 roku [Wikipedia]

Metody formalne pochodzą z co najmniej 1983 r. I zostały zastosowane w systemach o krytycznym znaczeniu dla bezpieczeństwa, takich jak pozbawione kierowcy metro w Paryżu, wykorzystujące metodę B.

W pierwszej i najbardziej abstrakcyjnej wersji, która nazywa się Abstract Machine, projektant powinien określić cel projektu. [Wikipedia]

Mogą to być niektóre z rzeczy, z których Kent Beck „pomógł pionierowi… ponowne odkrycie programowania w pierwszej kolejności”.

Co więcej: najwyraźniej projekt Mercasa z początku lat 60. XX wieku był pierwszym projektem oprogramowania wykorzystującym programowanie testowe i inne zwinne praktyki. Nie mogłem znaleźć żadnej wczesnej dokumentacji, ale oto raport z 2003 roku, który cytuje komunikację członków projektu:

Projekt Mercury przebiegał z bardzo krótkimi (półdniowymi) iteracjami, które były ograniczone czasowo. Zespół programistów przeprowadził przegląd techniczny wszystkich zmian i, co ciekawe, zastosował praktykę programowania ekstremalnego, polegającą na opracowywaniu testów, planowaniu i pisaniu testów przed każdym mikrostrementem.

Reszta raportu jest również interesująca, mówi dalej:

Najwcześniejsze znalezione przez nas odniesienie, które koncentrowało się na opisie i rekomendowaniu iteracyjnego rozwoju, to raport Briana Randella i FW Zurchera z IBM TJ Watson Research z 1968 r.

Oprócz zautomatyzowanych testów raport z 1968 r. Zaleca kodowanie równoległe i testowanie, jeśli nie najpierw test:

sol. Szczegółowy projekt, kodowanie i dokumentacja każdego bloku programu.
h. Projektowanie i dokumentowanie metod testowania dla każdego bloku programu równolegle z krokiem (g).

Jon Bently w Programming Pearls (pierwotnie opublikowany w 1986 r.) Nie wspomina konkretnie o programowaniu w pierwszej kolejności. Ale w rozdziale „Pisanie poprawnych programów” opisuje pisanie algorytmu, najpierw definiując warunki wstępne, niezmienniki i warunki dodatkowe, aw następnym rozdziale opisuje zautomatyzowane ramy testowania.

Nie jest to pierwsza próba, ale zdecydowanie położył trochę fundamentów.

Również,

Magazyn CIO , marzec 1993, Bug Busters , autor: Lucie Juneau, str. 84 :

Przypadki testowe ... można opracować nawet przed napisaniem kodu. Idealnie te przypadki są oparte na wymaganiach aplikacji ... Jeśli programiści przechodzą testy oparte na wymaganiach, zanim zaczną pisać kod, zaprojektują produkt, który może przejść te testy ... ”

To był Kent Beck , w swojej książce Extreme Programming , również wydanej w 1999 roku .