Тогда это уже не Test Driven Development?

Из чего такой вывод?

При последнем ты сначала пишешь тесты, а потом код к ним.

Именно так. И что?

Если тесты покрывают только 70-80%, то получается, что ты потом кучу кода дописываешь без тестов.

Ну так всякое бывает.

Не лучше ли тогда сначала код писать, а потом к нему тесты?

Не всегда. Вот например, типичный пример (у меня случает сплошь и рядом). Клиент репортит какой-то баг. После этого я пытаюсь этот баг повторить и понять в чем проблема. Потом я делаю тест, который должен быть красным. И только после этого я делаю фикс. Таким образом можно гарантировать, что баг исправлен и что исправление не повлияло ни на какие другие тестируемые фичи.

Если сначала написать код, а потом тест, то у тебя не будет гарантии того, что твой тест проверяет именно это исправление.

А ещё обычно начинается всё чинно, по методологиям, а потом аврал и на всё плюют - лишь бы успеть код нафигачить.

Такова жизнь :)

Если у вас тесты первичны и играют роль, как вы сказали, спецификации, то нет. А если сначала код, а потом тесты - то да.

Нет. Единожды написанный тест не должен меняться без веской причины. Причин таких может быть всего 2: 1) изменились требования и 2) изменились интерфейсы. Никаких других причин для изменения тестов нет.