Излишество TDD для маленьких проектов?

Когда вы думаете, что в результате написания кода могут произойти ошибки, которых вы не ожидаете, TDD имеет смысл.

Что ж, на самом деле решающим фактором для TDD является не количество людей (по крайней мере, это то, что подразумевает ваш вопрос), а, скорее, размер проекта.

Преимущества TDD в том, что весь код, который вы разрабатываете, в значительной степени будет проходить модульное тестирование. Таким образом, вы сэкономите много хлопот при последующем рефакторинге. Конечно, это действительно просто необходимо, когда ваш проект имеет приличный размер.

Я считаю, что это стоит делать почти для любого проекта. TDD и последующее регрессионное тестирование позволяет вам не только определить, работают ли компоненты в том виде, в котором вы их написали, но и по мере внесения изменений и рефакторинга. При условии, что ваши тесты достаточно полны, вы можете охватить сценарии для нечастых/невероятных краевых случаев и производить/поддерживать более надежный код.

В дальнейшем, на протяжении жизненного цикла проекта, циклы непрерывного тестирования избавят вас от ручного повторения тестов и сведут на нет очевидную вероятность их неправильного/неполного повторения.

Я и другие используем TDD в любом проекте, который больше, чем, скажем, несколько строк кода.

Как только вы поймаете ошибку тестирования, трудно не использовать TDD для чего-либо. Лично я обнаружил, что мой код улучшился в несколько раз благодаря TDD.

Я бы взял на себя возможность использовать TDD с небольшим проектом, просто чтобы у вас получилось замочить ноги. Это будет хороший опыт обучения, даже если вы поймете, что это не для вас.

Overkill? Вовсе нет. В дополнение к основному преимуществу - написанию кода, на который можно положиться, потому что вы подумали о том, как он может сломаться, - вы станете более дисциплинированным и потенциально более продуктивным с разработкой на основе тестирования. Возьмите любую из книг Pragmatic Programmer для получения советов и вдохновения.

Имеется ли в решении файл VSMDI? Я считаю, что этот файл необходим (НЕ ПРОВЕРЕН).

Команда sqlite3 .import не будет работать для обычных csv-данных, поскольку она рассматривает запятую как разделитель даже в кавычках.

Это включает в себя попытку повторного импорта csv-файла, созданного оболочкой:

Create table T (F1 integer, F2 varchar);
Insert into T values (1, 'Hey!');
Insert into T values (2, 'Hey, You!');

.mode csv
.output test.csv
select * from T;

Contents of test.csv:
1,Hey!
2,"Hey, You!"

delete from T;

.import test.csv T
Error: test.csv line 2: expected 2 columns of data but found 3

Похоже, мы должны преобразовать csv в список инструкций Insert, или, возможно, будет работать другой разделитель.

После того, как в SuperUser я увидел предложение использовать LogParser для работы с csv-файлами, я собираюсь изучить это.

Я всегда нахожу такой забавный вопрос. Какова альтернатива? Написание кода, который вы только компилируете и никогда не запускаете для проверки его правильности? Вы ждете, пока не развернетесь в производство, чтобы узнать, работает ли ваш класс вообще?

Если у нас никогда не было практики под названием TDD или до того, как JUnit был изобретен еще в 1997, не было ли тестирования кода? Конечно, было. Так почему это так важно сейчас, когда у вас есть тестовые рамки, чтобы помочь вам с этим?

Даже небольшой проект в сжатые сроки не захочет ждать до производства, чтобы узнать, работает ли он. Напишите тесты.

Это не обязательно для любого проекта, который «мал», но я определяю «мал» как менее одного класса.

У всего есть затраты-выгоды кривая.

Игнорируя многие из часто оспариваемых преимуществ TDD, TDD стоит того, если ваша реализация будет меняться достаточно часто, чтобы выгода от наличия автоматизированного набора тестов перевесила любые дополнительные затраты, которые могут быть связаны с первоначальной разработкой.

Из моего личного опыта я могу сказать следующее:

1. Каждый раз, когда я начинал один из моих личных маленьких хобби-проектов, я клялся разработать его, используя TDD.
2. Каждый раз я этого не делал.
3. Каждый раз я жалел об этом.

Маленькие проекты могут иметь привычку превращаться в большие проекты без вашего ведома, тогда вы бы хотели начать с TDD :)

Я слышал от одного члена нашей местной группы Agile, что она не считает TDD полезным для самых ранних этапов проекта, когда вы, по сути, делаете быстрые наброски, а вы я еще не совсем уверен, какую форму принимает эта вещь. Но как только у вас появятся некоторые идеи о том, как выглядят интерфейсы, вы можете начать использовать тесты, которые помогут вам их определить.

TDD - это еще один инструмент, подобный документации, для улучшения ясности кода. Это критически важно, когда другим людям нужно работать с вашим кодом, но многие из нас находят также очень полезными, когда оглядываются на наш собственный код. У вас когда-нибудь был какой-нибудь хобби-проект, к которому вы вернулись после того, как какое-то время отошли от него, натолкнулись на странный фрагмент кода и задались вопросом: «Какого черта я написал , что ?»

Я бы сказал, что это полностью зависит от заданного периода времени. Если у вас есть время, чтобы потратить почти вдвое больше времени, чем обычно, то дерзайте. Но, на мой взгляд, скорость в наши дни является одним из самых важных факторов (для конкурентоспособных компаний).