Наша контора полгода назад перешла с SVN на HG… лично меня к SVN уже не тянет — Hg выигрывает по всем статьям, а tortoiseHg с его екстеншенами — вообще сказка.
Вот именно, человек который идет по оживленной улице с сигаретой в зубах — моральный урод и не иначе. Я сам курю, но всегда стоя на месте и перед этим постараюсь убедиться что дым от моей сигареты никого не напряжет.
а мне нравятся тимбилдинги… правильно организованный тимбилдинг делает коллектив более дружным, а это очень важно. А кто не хочет — не ходит на них, у нас к участию не принуждают.
На улице – нет
Ну да… когда я иду с беременной женой, а перед нами идет какое-то чмо, за которым дым как от паровоза… И этим приходится дышать всем кто идет следом. Возникает желание догнать и засунуть ему эту сигарету в одно место.
имхо, в поиске не хватает фильтрации по скилам… например, я ищу разработчиков на 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 обьектов, или обращаться к реальным обьектам, перед забив их тестовыми данными — на это тоже потребуется немало усилий по реализации и сопровождению. Плюс вы таким образом уходите в сторону от концепции юнит тестирования.