Deutsch
Germany.ruФорумы → Архив Досок→ Программирование

SCRUM. У кого на работе считают, что используют?

26.09.18 10:27
Re: SCRUM. У кого на работе считают, что используют?
 
Программист коренной житель
в ответ AlexNek 25.09.18 23:56
скажем так - некая математическая функция. Все параметры вещественные числа.

Расчет некой математической функции безусловно можно протестировать юнит-тестами.


Это не страшно, я тоже много чего не встречал. Гляньте хотя бы время вычисления "функций" класса NP или даже тригонометрическую функцию вызовите достаточное число раз.

Толи лыжи не едут, толи я ... :)

Пусть у тебя задача подобрать пароль из 8 случайных символов, задано, что пароль может состоять только из латинских букв и цифр и является case sensitive. Итого у нас алфавит 26*2+10=62 символа получается около 8лярдов комбинаций, т.е. это достаточно долгая функция.

Можно ли ее протестировать быстро?

Безусловно да. И делается это так:

1) у нас есть некий интерфейс, за которым есть определяющий правильность пароля модуль

2) у нас есть наша функция.

Что мы делаем:

1) делаем фейк-модуль.

2) делаем 1-й тест: наша функция посылает пароль "аааааааа" и получает от фейка - ОК, после чего функция завершается и возвращает "аааааааа". Тест проверяет, что возвращенная функция именно "аааааааа".

3) делаем 2-й тест: наша функция посылает пароль "аааааааа" и получает от фейка - FAIL, посылает пароль "аааааааb" и получает от фейка - ОК, после чего функция завершается и возвращает "аааааааb". Тест проверяет, что возвращенная функция именно "аааааааb".

4) делаем 3-й тест: нам надо убедиться, что наша функция полностью проходит по словарю и генерит все возможные варианты. Для это мы делаем следующее: а) надо надо сделать возможным заинджектить словарь (например выделив его в виртуальную функцию или сделать инициализацию в протектед конструкторе) и б) нам надо добавить возможность установления длины пароля. В тесте мы устанавливаем длину пароля в 2 символа, и устанавливаем словарь, скажем, в "aA1", фейку говорим, что он всегда должен возвразать FAIL. Проверяем, что фейк был вызван ровно 9 раз, также проверяем, что фейку были переданы пороли "aa", "aA", "a1",... "11".

5) 2-й тест можно удалить

6) можно добавить тест, который бы проверял настройки по умолчанию, т.е. полный алфавит и что длина пароля именно 8 символов.


Очевидно, что несмотря на то, что задача по подбору пароля - занимает много времени, тесты будут работать быстро ;)


Так более понятно?

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


А если интерфейс находится в самом приложении тогда как?

Какая разница где? Приложение все равно имеет версию.


Или сборка предназначена исключительно для одного приложения?

Если сборка предназначена для одного приложения, то проблема обратной совместимости отсутствует.


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

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

Мне кажется, что ты сам не знаешь уже какую бы проблему придумать ;)


Это еще одна интересная проблема, особенно когда кто то успел "вклиниться".

Что значит "кто-то успел вклиниться"? У каждой компоненты своя ветка. Никаких вклиниваний там быть не может. В конце-концов, человечество изобрело code freeze.


А как заказчик мне скажет прога с каким тэгом у него стоит?

У заказчика есть номер версии. Теги заказчику ни к чему. Мэпить номер версии за тэг должен исполнитель, т.е. ты.


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

Гит умеет искать и по тэгам и по комментариям. Зачем нужно завязываться на хэш коммита я не понимаю.


либа Х является общей для Y проектов и если нужно делать серьезные изменения, то мы всегда делаем новую ветку.

Ну можно себе в ногу стрелять. Почему бы и нет?


Никак не доходит смысл TDD подхода именно для создания приложения, а не кучи функций.

В чем разница? Приложение же состоит из функций...


А в чем же конкретно прелесть?

В том, что тесты всегда актуальные. И должны быть всегда зелеными. Ну и тесты показывают как пользоваться тем или иным интерфейсом плюс к этому ограничения. Т.е. это своего рода документация.

 

Перейти на