Вот именно, человек который идет по оживленной улице с сигаретой в зубах — моральный урод и не иначе. Я сам курю, но всегда стоя на месте и перед этим постараюсь убедиться что дым от моей сигареты никого не напряжет.
а мне нравятся тимбилдинги… правильно организованный тимбилдинг делает коллектив более дружным, а это очень важно. А кто не хочет — не ходит на них, у нас к участию не принуждают.
На улице – нет
Ну да… когда я иду с беременной женой, а перед нами идет какое-то чмо, за которым дым как от паровоза… И этим приходится дышать всем кто идет следом. Возникает желание догнать и засунуть ему эту сигарету в одно место.
имхо, в поиске не хватает фильтрации по скилам… например, я ищу разработчиков на Java или .NET — что ж мне теперь лопатить всех подряд в поисках подходящих?
Ну и пусть американцы смотрят фильмы по своим ценам, а нашим по 2,5 уе пусть продают. Технически не составит сложности дифференцировать цены в зависимости от языка дублирования при просмотре фильма.
Не понятно как они цену в 5 уе складывали… Стоимость просмотра получилась практически такой же как в кинотеатре.
При том что себестоимость распространения фильмов через YouTube в разы меньше по сравнению с затратами на распространение их в сети кинотеатров. Могли бы сделать и подешевле.
Возможно, потребуется регламентировать процесс взаимодействия группы заказчиков с исполнителем. Как минимум, позволить общаться с разработчиком только создателю заказа(или избранным заказчикам).
Правильно, раз тестировщики не в состоянии найти все баги, давайте их всех уволим, раз юнит-тесты не в состоянии отловить все баги, давайте не будем писать юнит-тесты… список можно продолжать бесконечно.
Я так понимаю вы изобрели свой мегапроцесс, который позволяет полностью исключить возможность возникновения багов? Предоставьте пожалуйста на суд публике статью с описанием такого процесса, чтоб все заткнулись и поняли, что устоявшиеся мировые практики по разработке ПО это УГ, и надо делать по вашему.
Методология юнит-тестирования, которую проповедует XP, не является серебрянной пулей и не сопособна защитить от всех багов. Юнит-тесты никогда не заменят живых тестировщиков. Оба подхода должны дополнять друг друга, особенно для крупных проектов.
# Прохождение теста не должно зависеть от внешних систем(сервера баз данных, веб-сервера, файловая система, контроллеры внешних устройств), если он не предназначен для тестирования взаимодействия с этими системами."
Одно противоречит другому. Таки если я написал юнит-тест для тестирования взаимодействия с этой системой, как мне ее оттестировать, не инициализируя эту систему?
Если вы написали автоматический тест для тестирования взаимодействия вашего модуля со сторонней системой, то это уже не юнит-тест а integration test. Само по себе понятие «юнит-тест» предполагает тестирование логики реализованной в вашем модуле(группе модулей).
Ну и да. Идея о том, что юнит-тест должен работать без тестового окружения (например, БД) приводит к тому, что нам приходится писать два разных теста — сначала юнит-тест, который проверит, что на моке все работает, а потом юнит-тест, который проверит, что БД работает так же, как мок. А вы пробовали когда-нибудь найти все особенности поведения крупного DAL? Когда на моке, который возвращает IQueryable, собранный из массива данных в памяти, все работает (потому что работает LINQ to objects), а на боевому запуске, где IQueryable из датаридера, все падает (потому что работает, скажем, LINQ to SQL, в котором нет поддержки нужного метода).
Правильный подход в данном случае — написание тестов для:
1 — тестирования логики которая формирует IQueryable на соотвествие формирования запросов.
2 — тестирования логики LINQ to SQL на наличие поддержки необходимых методов.
Для большого проекта вторую группу тестов вам понадобится реализовать всего один раз.
по сути, само юнит-тестирование не от хорошей жизни… а behavioral testing это всего лишь один из подходов, ни больше ни меньше. А говорить что какой то из подходов хуже/лучше бессмысленно, нужно просто правильно их использовать, и да будет счастье.
А как насчет такого способа:
Для таблицы %TABLENAME% имеем суррогатный ключ ID+VERSION_NUMBER плюс стандартные поля CREATED, UPDATED.
Создаем таблицу %TABLENAME%_CURRENT_VERSION(ID, VERSION_NUMBER). Для каждой новой версии записи — создаем дубликат в %TABLE_NAME%, в нем инкрементируем VERSION_NUMBER, присваиваем новое значение UPDATED, и обновляем соответствующее значение VERSION_NUMBER в таблице %TABLENAME%_CURRENT_VERSION для данного ID.
Выборка актуальных версий на конкретную дату производим по дате UPDATED,
Актуальную версию выбираем через INNER JOIN к таблице %TABLENAME%_CURRENT_VERSION
При необходимости можно зашедулить перенос устаревших версий в таблицу дубликат, если размеры таблиц начнут сказываться на производительности.
Unit-тестирование условно делится на два подхода:
* state-based testing, в котором мы тестируем состояние объекта после прохождения unit-теста
* interaction (behavioral) testing, в котором мы тестируем взаимодействие между объектами, поведение тестируемого метода, последовательность вызовов методов и их параметры и т.д.
… Иногда просто удобнее проверить состояние объекта, а иногда – его взаимодействие с другими объектами. Поэтому эти два подхода прекрасно уживаются вместе, когда вы понимаете, о чем идет речь, и что именно вы хотите сейчас проверить.
Рефакторинг тестов никто не отменял. Учитывая что тестовых ситуаций могут быть десятки, можно инициализацию тестовой среды вынести в отдельные методы и использовать их повторно с передачей нужных параметров.
А если тестовая ситуация одна, то без использования моков вам понадобится создавать свои реализации fake обьектов, или обращаться к реальным обьектам, перед забив их тестовыми данными — на это тоже потребуется немало усилий по реализации и сопровождению. Плюс вы таким образом уходите в сторону от концепции юнит тестирования.
используя такой подход, вы завязываете реализацию своих тестов на внутренней структуре объектов, а не на интерфейсе объектов, иначе говоря, тесты будут ломаться, когда код будет фактически работоспособным.
Упавшие тесты не составит особого труда пофиксить, а что вам даст уверенность что после изменения внутренней структуры класса, вы не поломали его логику?
Я для того и упомянул об особенностях юнит тестирования в обзоре, — обратите внимание на пункт Для чего нужно юнит тестирование.
При адекватном использовании моков, такие неоправданные падения тестов будут скорее исключением чем правилом.
Во вторых, упавшие тесты заставляют держать руку на пульсе — человек который их фиксит, волей-неволей должен вникнуть в логику работы класса который он изменил(а юнит тесты как раз и документируют логику классов). Это особенно важно в коллективной разработке, когда над одним проектом трудятся десяток и более девелоперов.
Наиболее эффективными (но и трудоемкими в написании) являются тесты, основанные на использовании тестовых реализаций
Вам не кажется что это те же самые моки, только реализованные вручную? Какие преимущества с точки зрения юнит-тестирования дает такой подход(кроме увеличения скорости работы тестов и простоты набивки тестовых данных)?
Ну да… когда я иду с беременной женой, а перед нами идет какое-то чмо, за которым дым как от паровоза… И этим приходится дышать всем кто идет следом. Возникает желание догнать и засунуть ему эту сигарету в одно место.
При том что себестоимость распространения фильмов через YouTube в разы меньше по сравнению с затратами на распространение их в сети кинотеатров. Могли бы сделать и подешевле.
Я так понимаю вы изобрели свой мегапроцесс, который позволяет полностью исключить возможность возникновения багов? Предоставьте пожалуйста на суд публике статью с описанием такого процесса, чтоб все заткнулись и поняли, что устоявшиеся мировые практики по разработке ПО это УГ, и надо делать по вашему.
Если вы написали автоматический тест для тестирования взаимодействия вашего модуля со сторонней системой, то это уже не юнит-тест а integration test. Само по себе понятие «юнит-тест» предполагает тестирование логики реализованной в вашем модуле(группе модулей).
Правильный подход в данном случае — написание тестов для:
1 — тестирования логики которая формирует IQueryable на соотвествие формирования запросов.
2 — тестирования логики LINQ to SQL на наличие поддержки необходимых методов.
Для большого проекта вторую группу тестов вам понадобится реализовать всего один раз.
по сути, само юнит-тестирование не от хорошей жизни… а behavioral testing это всего лишь один из подходов, ни больше ни меньше. А говорить что какой то из подходов хуже/лучше бессмысленно, нужно просто правильно их использовать, и да будет счастье.
Для таблицы %TABLENAME% имеем суррогатный ключ ID+VERSION_NUMBER плюс стандартные поля CREATED, UPDATED.
Создаем таблицу %TABLENAME%_CURRENT_VERSION(ID, VERSION_NUMBER). Для каждой новой версии записи — создаем дубликат в %TABLE_NAME%, в нем инкрементируем VERSION_NUMBER, присваиваем новое значение UPDATED, и обновляем соответствующее значение VERSION_NUMBER в таблице %TABLENAME%_CURRENT_VERSION для данного ID.
Выборка актуальных версий на конкретную дату производим по дате UPDATED,
Актуальную версию выбираем через INNER JOIN к таблице %TABLENAME%_CURRENT_VERSION
При необходимости можно зашедулить перенос устаревших версий в таблицу дубликат, если размеры таблиц начнут сказываться на производительности.
приведу цитату из очень хорошей статьи:
А если тестовая ситуация одна, то без использования моков вам понадобится создавать свои реализации fake обьектов, или обращаться к реальным обьектам, перед забив их тестовыми данными — на это тоже потребуется немало усилий по реализации и сопровождению. Плюс вы таким образом уходите в сторону от концепции юнит тестирования.
Упавшие тесты не составит особого труда пофиксить, а что вам даст уверенность что после изменения внутренней структуры класса, вы не поломали его логику?
Я для того и упомянул об особенностях юнит тестирования в обзоре, — обратите внимание на пункт Для чего нужно юнит тестирование.
При адекватном использовании моков, такие неоправданные падения тестов будут скорее исключением чем правилом.
Во вторых, упавшие тесты заставляют держать руку на пульсе — человек который их фиксит, волей-неволей должен вникнуть в логику работы класса который он изменил(а юнит тесты как раз и документируют логику классов). Это особенно важно в коллективной разработке, когда над одним проектом трудятся десяток и более девелоперов.
Вам не кажется что это те же самые моки, только реализованные вручную? Какие преимущества с точки зрения юнит-тестирования дает такой подход(кроме увеличения скорости работы тестов и простоты набивки тестовых данных)?