Я занимаюсь тестовой разработкой кода на С ++, и одна вещь, которую я нахожу неловкой, это то, что мне нужно создать много файлов для каждого класса, например:
iread.h
read.h
read.cpp
mockread.h
mockread.cpp
testread.h
testread.cpp
И добавьте их в разные папки (фильтры) в моем проекте.
В результате я в значительной степени удалил и cpp файлы. Однако это нарушает правило, согласно которому модульные тесты должны создаваться как можно быстрее. Поэтому я хотел бы прекратить делать это, если бы мог только ускорить развитие на других фронтах.
Говоря по существу, я буквально испытываю головную боль, когда работаю с разработкой, управляемой тестами, в C ++ из-за накладных расходов, связанных с домашним хозяйством. У меня нет той же проблемы при работе с питоном.
Одним из улучшений, которые я недавно сделал, является использование макета Google и автоматическое создание макетов из их интерфейсов. Так что это, безусловно, улучшение.
Однако мне кажется, что я смогу еще больше сократить накладные расходы за счет использования плагинов, которые автоматически создают заглушки для всех классов, которые мне нужны при tdding определенного класса. Существуют ли такие плагины? Будет ли сложно разработать такой плагин в отношении Eclipse, VS 2005, VS 2008 и VS 2010 (извините, но время от времени мне приходится работать в разных средах).
Другой проблемой является количество навигации, которое мне нужно сделать, чтобы найти классы (макеты, тесты и т. Д.) Для данного тестируемого класса в Project Explorer (как он вызывается в VS). У меня есть идея остановить группировку файлов в проводнике проекта следующим образом:
+interfaces
+namespaceA
iread.h
+headers
+namespaceA
read.h
+source
+namespaceA
read.cpp
+mocks
+namespaceA
mockread.h
mockread.cpp
+tests
+namespaceA
testread.h
testread.cpp
и сделайте это вместо:
+namespaceA
read.cpp
read.h
readi.h
readmock.cpp
readmock.h
readtest.cpp
readtest.h
Это объединит файлы, связанные с определенным классом, вместе в обозревателе решений. Это хорошая идея? Как дела? Было бы странно иметь интерфейс IRead в файле readi.h ... Майкл Фезерс пишет, что он вообще не использует I, но я предпочитаю его использовать ... Подавляющее большинство моих интерфейсов имеют только один класс реализации связанные с ними.
Как вы организуете свои проекты на диске?
Есть еще советы? У тебя тоже болит голова?
Спасибо
Barry