Тест проект

Прикреплённые файлы

Я с самого начала именно это и сказал

А зачем мы с вами тогда так долго беседуем? Консенсус. Вам скрам не нужен, все разошлись.

Но даже программисту робота нужно будет очень постараться, чтобы добавить подобную функцию.

Ух, блин. Прям как с мурром разговариваю... Придумайте сами, что у вас может пойти не так из-за ошибки в вашем коде.

То бишь чудо скрам метод принесет это все на тарелочке с голубой каемочкой - так это нужно понимать?

Аскс! Выходишь в поле ночью, зарываешь 10 тысяч евро монетами в поле, посыпаешь солью говоришь три раза "скрам приди - проблемы забери" и ждёшь пока вырастет качество кода, документация и новые программисты. И, что характерно, всё на тарелочках да с голубыми каёмочками. А там только собирай! А то перезреют и убегут к конкурентам. Именно так это и работает.

А что, если я буду со всем соглашаться так я пойму быстрее?

Не-а. А вот если начнёте пытаться понимать - то да.

скажем так - некая математическая функция. Все параметры вещественные числа.

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

Это не страшно, я тоже много чего не встречал. Гляньте хотя бы время вычисления "функций" класса 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 подхода именно для создания приложения, а не кучи функций.

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

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

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

Чтобы продемонстрировать работу NSubstitute я домавил еще пару тестов для ViewModel'и. Тесты эти проверяют, что проперти правильно устанавливаются и уведомляют WPF о том, что можно обновить Bingings.

Прикреплённые файлы

NSubstitute

Спасибо, еще не слышал. Начну с примера пожалуй.

пока студия обновляется.....

А вы что еще на НЕТ4.0 должны сидеть? Отчего проперти "по старинке" обновляете с именем?

В чем смысл инициализации viewmodel в XAML?

А зачем мы с вами тогда так долго беседуем?

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

Как будет чуть больше времени попробую систематизировать Ваши заметки.

Придумайте сами, что у вас может пойти не так из-за ошибки в вашем коде.

Можно валом, что придумать и вспомнить. Самая "страшная" проблема была - вылет без всякой инфы и то что рабочее место у клиента определили прямо под кондиционером.

Кстати, вылет (OutOfMemory) до сих так и не удалось повторить. И тулзами гонял и "счетчик памяти" установил - не растет зараза и все.

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

Вот даже примерчик, для вас:

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

А вот если начнёте пытаться понимать - то да

А что Вы можете как то измерить логику другого человека?

Что еще осталось непонятным:

-зачем нужен конвертер, если и так работает - пример

-зачем проверять проперти если можно обеспечить имя "автоматом" (nameof или атрибутом)

Прикреплённые файлы

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

А какой смысл в тестирование фейка? Как же покрытие функции да и правильность результатов расчета?

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

ну да 3 по 10 этого только тысяча, а 3 по 100 уже миллион

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

Так именно об этом я и говорил.

используемые компоненты должны быть закомичены в виде бинарников

ой, не хочется открывать новую дискуссию.

Берешь известную версию и собираешь продукт.

Для этого ее нужно иметь. Часто попадалось, что забывают/ешь все репо пометить.

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

А их не нужно придумывать, они сами появляются.

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

У каждой компоненты своя ветка. Никаких вклиниваний там быть не может

А что ни "мастера" ни "девелопмент" у вас нет?

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

Как часто это нужно делать и как быть уверенным, что не допустил ошибки?

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

потому что это уникальный ключ для коммита который всегда есть.

Ну можно себе в ногу стрелять

А в чем ошибка делать новые ветки для изменений?

Приложение же состоит из функций...

У кого как. У меня в голове приложение прежде всего "состоит" из объектов и потоков данных. И пока не соберутся правильные объекты до функций особого дела нет.

А что Вы можете как то измерить логику другого человека?

Логику мерять я не умею да и единиц измерения пока не придумали. А вот отношение к новшествам замечать - со временем получается. Если в ответ на описание чего-то нового слышишь "а у нас и так всё работает", "это бзик", "а нам не надо" - то можно быть увереным что человеку это новое 1. абсолютно не нужно (по его мнению) 2. он не пытается понимать что же там может быть подходящего, а просто "защищает" своё нынешнее положение от этих отвратительных новшеств.

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

А вы что еще на НЕТ4.0 должны сидеть?

Мы да, сидим на .Net 4.0

Отчего проперти "по старинке" обновляете с именем?

По привычке.

В чем смысл инициализации viewmodel в XAML?

Зачем писать код, когда можно засунуть в XAML? :D

-зачем нужен конвертер, если и так работает - пример

Ну для инта не нужен (хотя помню у меня как-то были проблемы и я должен был сделать конвертер, но условий уже не помню).

-зачем проверять проперти если можно обеспечить имя "автоматом" (nameof или атрибутом)

Не надо - удали тест :) В любом случае, может быть так, что одним сеттером обновляется сразу несколько пропертей.

Ну и плюс к этому ты узнал о NSubstitute :)

А какой смысл в тестирование фейка?

Фейк никто и не тестирует. С чего ты это взял?

Как же покрытие функции да и правильность результатов расчета?

Покрытие данной функции будет максимально возможное. Ну и правильность соответственно. Какая разница генерить пароль в 2 символа или в 8? Правила одинаковые, логика тоже.

ну да 3 по 10 этого только тысяча, а 3 по 100 уже миллион

Ты это к чему?

Часто попадалось, что забывают/ешь все репо пометить.

Это потому что у вас нет процесса "релиза". С чек листом и четкой последовательностью действий :)

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

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

А что ни "мастера" ни "девелопмент" у вас нет?

Есть конечно :) Но, в случае, когда либа Х используется несколькими продуктами, то для либы Х свои "мастер" и "девелопмент", а для продукта С - свои :)

Как часто это нужно делать и как быть уверенным, что не допустил ошибки?

Зависит от процессов, кто-то делает метки при каждом handover, кто-то только при release. Чтобы быть уверенным, что не допустил ошибку нужна автоматизация :) Тут уж кто во что горазд. кто-то использует Maven, на моих последних 2-х проектах мы делали такую систему под себя.

А в чем ошибка делать новые ветки для изменений?

Для изменений никаких. А сливать общую либу со своим продуктом - выстрел себе в ногу :)

тесты будут работать быстро ;)

-----

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

Для понимания - в vиндощом полиси есть понятие - число неудачных попыток до блокирования аккаунта.

А знаете как обычно реагирует человек

Иначе говоря - использование стандартного алгоритма во всех случаях, а если нестандартно, то неправильно.

Ну давайте попробуем Ваш путь - CI на 40 часовой проект, какие плюсы я получаю. И также какие минусы, по вашему мнению.

Мы да, сидим на .Net 4.0

У нас тоже долго было, но потом решили, что нефиг ХП больше поддерживать. Да и вин 7 уже тяжело стало найти.

Если вдруг захотите nameof пользовать - она выполняется runtime.

Зачем писать код, когда можно засунуть в XAML?

А если в конструктор параметр надо передать?

Но другой причины нет?

Фейк никто и не тестирует. С чего ты это взял?

так из описания понял.

Какая разница генерить пароль в 2 символа или в 8?

Не знаю особенности данной функции, но часто диапазон имеет решающее значение.

Ты это к чему?

К тому что по времени выполнения будет разница, вызывать функцию тысячу раз или миллион.

Это потому что у вас нет процесса "релиза". С чек листом и четкой последовательностью действий

А можно примерчик вместе с вменяемой системой сборки, чтобы работала на любом компе, в любом месте при ограниченном времени без интернета.

А сливать общую либу со своим продуктом - выстрел себе в ногу

А в чем конкретные проблемы? Пока не попалось ни одного минуса, хотя долго боялся это делать.

Опять таки, для вашей ситуации это может быть совершенно неприемлемо.

Возвращаясь к TDD.

Получается "вначале тест" не следует понимать буквально.

А пишем вначале все приложение, а после начинаем с этого?

        [TestMethod]
        public void Sum_2plus2_4()
        {
            // Arrange
            MainModel model = new MainModel();
            // Act
            int res = model.Sum(2, 2);
            // Assert
            Assert.AreEqual(4, res);
        }
        [TestMethod]
        public void Sum_2plus3_5()
        {
            // Arrange
            MainModel model = new MainModel();
            // Act
            int res = model.Sum(2, 3);
            // Assert
            Assert.AreEqual(5, res);
        }

Вот только не доходит чем это мне поможет сделать более лучшую реализацию.

И что говорит теория относительно данного вызова функции?

     [TestMethod]
        public void Sum_Test05()
        {
            // Arrange
            MainModel model = new MainModel();

            // Act
            int res = model.Sum(Int.MaxValue, int.MaxValue);

            // Assert
            Assert.AreEqual(-2, res);
        }

Начал собирать информацию - получил аж 4 страницы ворда. попробую по частям выложить

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

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

Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом:

1. Для начала необходимо выбрать «Владельца продукта» — человека, обладающего видением того, что вы собираетесь создать или достигнуть.
2. Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.
3. Нужно выбрать «Скрам-мастера» — того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.
4. Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта». Он может развиваться и изменяться на протяжении всего срока реализации проекта.
5. Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения.
6. Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание, на котором они запланируют спринт — определенное время для выполнения части заданий. Продолжительность спринта не должна превышать один месяц. За каждый спринт команда нарабатывает определенное количество баллов. Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель — постоянно превосходить свои собственные результаты — «наращивать динамику производительности».
7. Чтобы все участники были в курсе состояния дел нужно завести скрам-доску с тремя колонками: «Нужно сделать, или бэклог»; «В работе»; «Сделано». На доску участники клеят стикеры с заданиями, которые в процессе работы поочередно перемещаются из колонки «Бэклог» в колонку «в работе», а затем в «сделано».
8. Ежедневно проводится скрам-собрание. По выражению Джеффа Сазерленда «это пульс всего процесса Scrum». Суть его проста — ежедневно, на ходу, пятнадцать минут на то, чтобы все дали ответы на три вопроса: «Что ты делал вчера, чтобы помочь команде завершить спринт?», «Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?», «Какие препятствия встают на пути команды?».
9. По завершении спринта команда делает его обзор — проводит встречу, на которой участники рассказывают, что сделано за спринт.
10. После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.

Когда все участники поделятся своими результатами работы, команда начинает разбирать все, что было сделано за спринт, но делая упор не на обсуждение продукта, а на то, каким образом он делался. «Как улучшить сотрудничество в следующем спринте? Что препятствовало в последнем спринте? Из-за чего мы продвигаемся не так быстро, как хотим?» — вот вопросы, которые они ставят перед собой».

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

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

Критерии эффективности

• Гибкость. (пожалуй, самый главный) Как часто в процессе разработки будут вносится изменения в требования.
• Организация. Готовы ли вы к изменениям в организации. Если нет - забудьте про скрам, не взлетит.
• Личные качества. Готовы разработчики брать на себя ответственность и принимать решения?
• Размер проекта. Если время разработки проекта 1-2-3 недели - не стоит затеваться со скрамом
• Срок жизни проекта. При малом сроке жизни Скрам не нужен.
• Требования к качеству (понятный, легко изменять) кода / документации.

Эффективность предлагают измерять метриками

http://agilerussia.ru/practices/scrum-metrics/

Аккуратность оценки задачи - Насколько хорошо команда оценивает более детальные куски работы

Влияние затруднений - Угрозы для проекта и возможные причины задержек

Время выгорания – burnout time

Средняя скорость - Размер и количество пользовательских историй (и / или других пунктов бэклога продукта) , которые команда делает в среднем в типичном спринте

Проектное ETD (estimated time of delivery – оценочное время поставки) - Она дает нам грубую оценку (не гарантию) того, когда будет сделан весь бэклог (или если вам так нужно, часть его), базируясь на средней скорости команды