Isso depende TOTALMENTE do tipo de trabalho que você está fazendo. Para muitas situações, o Test-Driven-Development, como você está fazendo atualmente, é definitivamente o caminho a percorrer. No geral, você gastará menos tempo no projeto, já que você não terá que constantemente voltar e consertar bugs e casos extremos que não foram contabilizados pela primeira vez. Com a primeira opção, sim, você terminará em tempo recorde, mas depois gastará uma boa parte do tempo voltando e consertando todos os erros.
Dito isto , se você está em uma situação onde você precisa ter um produto fora da porta o mais rápido possível (talvez você esteja tentando vencer a competição pela vantagem do "primeiro ao mercado"), jogue TDD pela janela e consiga algo funcionando e lá fora. Um lote de ótimos produtos aconteceu dessa maneira. Seu produto não o levará a qualquer lugar se você estiver polindo e consertando bugs se um concorrente com um produto "bom o suficiente" estiver comendo o seu almoço.
Considere o Facebook. Mark Zuckerberg criou o Facebook em seu dormitório com PHP e MySQL, numa época em que provavelmente outras vinte pessoas ou organizações estavam planejando ou já lançando sites de redes sociais. Parte da razão para o sucesso do Facebook foi que ele saiu da porta com pressa e venceu boa parte da competição apenas porque foi o primeiro no mercado de faculdades.
Se você tiver tempo: teste de unidade .
Se você está em uma corrida: código , e faça-o funcionar - se preocupe com os erros depois.
EDIT: Obviamente, você não pode liberar um produto que é tão buggy inutilizável. Ao usar o método "fora da porta", você precisa perceber quando a caça e correção de bugs adicionais só adicionam valor marginal ao seu produto quando comparado com o lançamento agora.