Хорошо, я знаю, что уже были вопросы о начале работы с TDD .. Тем не менее, я думаю, что я вроде как знаю, что общее согласие состоит в том , чтобы просто сделать это , однако, у меня, кажется, есть следующие проблемы, чтобы получить мою голову в игре:

• При работе с коллекциями, do все равно будет тестировать на очевидный add/remove/inserts успешный, даже если он основан на дженериках и т. д., где мы вроде "know" его будем работать?
• Некоторые тесты кажутся бесконечными, чтобы их реализовать.. Например, при работе со строковым выводом, есть ли способ "better" для такого рода вещей? (например, протестируйте объектную модель перед синтаксическим анализом, разбейте синтаксический анализ на небольшие операции и протестируйте там) на мой взгляд, вы всегда должны тестировать "end result", но это может сильно варьироваться и быть утомительным для настройки.
• У меня нет тестовой платформы для использования (работа не будет платить за нее), поэтому я могу "practice" больше. Есть ли хорошие из них, которые являются бесплатными для коммерческого использования? (на данный момент я использую старые добрые Debug.Assert :)
• Наверное, самый большой.. Иногда я не знаю, чего ожидать от NOT.. Я имею в виду, что вы получаете свой зеленый свет, но я всегда беспокоюсь, что могу пропустить тест.. Вы копаете глубже, чтобы попытаться взломать код, или оставляете его в покое и ждете, что все это упадет позже (что будет стоить больше)..

Поэтому в основном то, что я ищу здесь, - это не " просто сделай это ", а больше " я сделал это, имел проблемы с этим, решил их этим ".. Личный опыт :)

//jquery
$("select").wrap('<span class="sel_wrap"></span>').wrap('<span class="sel_wrap_inner"></span>');

/*Стили*/
.sel_wrap {
    background: url(images/bg_buttonwrap.png) left top no-repeat;
    height: 24px;
    display: inline-block;
    overflow: hidden;
}
.sel_wrap_inner {
    background: url(images/bg_button_drop.png) right top no-repeat;
    display: inline-block;
    height: 24px;
    overflow: hidden;
}
select {
    background: none;
    border: none;
    margin: 3px -24px 0 5px;
}

Представьте себе сцену, вы обновляете какой-то устаревший код Sybase и натыкаетесь на курсор. Хранимая процедура создает результирующий набор в таблице #temporary, которая полностью готова к возвращению, за исключением того, что один из столбцов не очень удобочитаем, это буквенно-цифровой код.

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

declare c_lookup_codes for
select distinct lookup_code
from #workinprogress

while(1=1)
begin
    fetch c_lookup_codes into @lookup_code

    if @@sqlstatus<>0
    begin
        break
    end

    exec proc_code_xref @lookup_code @xref_code OUTPUT

    update #workinprogress
    set xref = @xref_code
    where lookup_code = @lookup_code
end

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

_NB: для целей этого примера вы также можете представить, что результирующий набор находится в области 500k строк и что существует 100 различных значений look_up_code и, наконец, что невозможно иметь таблицу со значениями внешней ссылки, так как логика в proc_code_xref слишком arcane._