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?

testing history

— Eric Weilnau
źródło

To nie jest subiektywne. Czy to jest istotne? Nie wydaje mi się Jeśli masz dobry motyw, aby ponownie otworzyć to pytanie, opublikuj post na meta.programmers.stackexchange.com

— Maniero

@bigown: Nie jestem pewien, czy rozumiem. Czy mówisz, że zamknąłeś to pytanie, ponieważ nie jest ono subiektywne lub że nie jest względne?

— Eric Weilnau,

Jest to wyraźnie obiektywne.

— Maniero

Jest to również związane z programowaniem i interesujące, i chociaż może być jedna prawdziwa odpowiedź, udowodnienie, że nie jest to łatwe. Gdzie jeszcze to idzie? ProgrammingHistory.stackexchange?

— AShelly

możemy tutaj pozwolić na obiektywne pytania - wolimy pytania subiektywne, ale podobnie jak Stack Overflow ma kilka SUBIEKTYWNYCH pytań, które przetrwają, ta strona może zawierać kilka CELÓW pytań, które przetrwają. (Nie spodziewałbym się jednak, że zobaczę tutaj pytania „jak sprawić, by ten kod Perla zadziałał”)

— Jeff Atwood

Odpowiedzi:

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).

— Hugo
źródło

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 ... ”

— AShelly
źródło

Druga edycja została opublikowana 7 października 1999 r. Według Amazon.com. Pierwsze wydanie zostało opublikowane w 1986 roku. Czy to odniesienie w pierwszym wydaniu?

— Eric Weilnau,

Przeczytałem tylko drugie wydanie. Przedmowa wydaje się wskazywać, że jedyny rozdział „Pisanie poprawnych programów” był w pierwszym wydaniu, rozdział dotyczący automatycznych testów jest nowszy.

— AShelly

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

alternatywny tekst

Według Amazon.com ta książka została pierwotnie opublikowana 5 października 1999 r. To prawie 3 miesiące po opublikowaniu Refaktoryzacji. Zredagowałem swoje pytanie, aby podać dokładną datę publikacji według Amazon.com. Nie czytałem książki Kenta, ale zakładam, że zawiera ona znacznie więcej informacji na temat programowania pierwszego testu.

— Eric Weilnau,

Interesujące jest to, że na tylnej okładce tej książki napisano, że Kent Beck „pomógł pionierowi… ponowne odkrycie programowania w pierwszej kolejności”. Skąd to odkrył?

— AShelly,

Ciekawe znalezienie AShelly!

@AShelly: Kilka lat temu Kent Beck wygłosił mowę na RailsConf. Opisał w nim, jak wymyślił TDD, i wspomina, że przeczytał o tym w starym artykule z lat 60.

— Jörg W Mittag,