На разработке через тестирование, НО НАОБОРОТ
Я использую в () функция и имею оператор [], звонят в () функция негласно, таким образом, оператор [] является просто синтаксическим сахаром. Это то, как станд.:: вектор делает это, таким образом, это походит на разумное (с приоритетом) способ сделать это.
Теперь для полного синтаксического сахарного взлома (не может сказать, я полностью рекомендую это, но мог бы ударить Ваше воображение):
class Widget
{
Widget& self;
public:
Widget() :self(*this)
{}
void operator[](int)
{
printf("hello");
}
void test()
{
//scripting like sugar
//you pay the price of an extra reference per class though
self[1];
}
};
int main(int argc, char* argv[])
{
Widget w;
w[1];
w.test();
return 0;
}
Также, если Вы хотите сделать, это бесплатно, не оплачивая стоимость ссылки, И является подписчиком некоторой злой секты, выделенной тому, чтобы заставлять программистов пострадать, Вы могли сделать:
#define self (*this)
На самом деле я думаю, что это - то, как большинство дескрипторов реализовано в API NS Apple...
4 ответа
Если вы сначала не напишите свои тесты, то это, вероятно, не TDD. С TDD вы обычно пишете тест, наблюдаете, как он терпит неудачу, а затем реализуете его, чтобы он прошел.
Преимущества перед вашим рабочим процессом:
- Ваши тесты могут провалиться! Слишком легко создать тест, который просто не может потерпеть неудачу. И, как указывает Эрик, если вы сначала не напишете тест и не увидите, как он потерпит неудачу, как вы узнаете, что тест на самом деле проверяет только что реализованную вами функциональность?
- Ваш код определенно поддается тестированию. Хотя я уверен, что вы следуете тестируемым методикам, разработка с самого начала тестирования гарантирует, что код будет определенно тестируемым, иначе вы бы не написали код: -)
- Переворачивает ваши решения «с ног на голову». Спорно один этот, но TDD заставляет вас думать о том «что вам нужно», а не "
Если вы напишете тесты потом, действительно ли они управляют разработкой / дизайном? Я бы так не подумал.
Чтобы расширить ответ Стивена Роббинса: Если ваш тест не проваливается до того, как вы его пройдете, как вы узнаете, что это правильный тест ?
Управляется ли дизайн соображениями тестирования? Если так, то развитие стимулировало тестирование. Так и должно быть.
Написание тестов в первую очередь абсолютно гарантирует, что тестирование движет развитием. И это имеет тенденцию ограничивать рефакторинг.
Если вы хотите сначала написать весь код, а затем провести рефакторинг, вы используете тестирование для стимулирования разработки (что хорошо). Однако вы, вероятно, напрасно тратите время, сначала написав весь код, а потом все реорганизуя (что не так хорошо). Использование TDD облегчит это; написание тестов до кода также сократит время разработки за счет экономии на рефакторинге.
Обдумывание дизайна и кодирования вашего программного обеспечения с последующим тщательным добавлением тестов, чтобы убедиться, что вы что-то не забыли, - хороший способ продолжить работу в моей книге.
Вы думаете о своем коде как с точки зрения разработки программного обеспечения, так и с точки зрения тестирования. Я стараюсь разрабатывать код и тестировать параллельно, никогда не следую парадигме «сначала напишите свой тест», потому что в результате получается код, который выполняет ваши тесты, а не ваш дизайн.
Риск в TDD состоит в том, что этап проектирования не учитывается. Если вы создаете свои тесты, пытаясь взломать свой код всеми возможными способами, тогда исправьте проблемы, которые выявляет ваш тест, вы получите стабильный код. Мне пришлось реорганизовать код, написанный с помощью TDD, который в лучшем случае имел качество прототипа, это не метод, обеспечивающий хороший код, а умственные усилия, которые вы вложили в него.