Поддержу, что работать так можно, хотя это и является дисциплиной специальной олимпиады. Красные линии зеленого цвета — очевидная аллегория: не-технический персонал в большинстве случаев действительно «не вкуривает», что вообще написано. Но в случае с видео дурные требования еще на стадии совещания.
Уточняем про перпендикулярность: 7 перпендикулярных любой стороне листа линий (т.е. 7 параллельных). Вносим коррективы: 2 линии должны быть зеленого цвета, две — нанесены прозрачным выпуклым гелем. остальные — красные. Скорее всего заказчик этого и хотел, но идиоты из видео «так поняли» и «так записали» требования.
А надуть шарик — вообще легко: такса $100 в час + оплата командировочных. Т.к. я не специалист в надувании шариков, это займет рабочий день.
И да, почему бы не нарисовать котенка слева снизу.
Здорово. Как раз гуглил на тему софта для визуализации. Смонтировать то ясно как, а 3D, видимо, проще самому запрограммировать, то что действительно хочется, чем пытаться нарезать из готовых.
А в чем цель статьи? Посмеяться на тему? Заставить задуматься? Простая инверсия данных советов не даст рецепта «как писать хайлоад-приложения».
В разработке действительно больших и сложных систем нет серебряных пуль. А вопросы когда лучше докупить сервер, а когда заняться оптимизацией вообще каждый раз решаются отдельно, и далеко не всегда понятно, что окажется рентабельнее в долгосрочном плане.
Я участвовал в таком проекте. Правда мы не называли это SbE и, конечно, у нас были свои особенности. Использовали Jira, svn, Team City, SpecFlow, MsTest.
Пробуйте. Если даже сроки точнее не станут, то проговорите командой функционал и лучше уложите это в голове. Задача так гораздо яснее становится. Одна голова хорошо, а две — лучше.
Возможно, каждому свое. Один мой коллега (разработчик) в корне изменил подход к разработке, именно после прочтения Реворка. Какие-то вещи, которые кажутся очевидными для одного человека, неожиданно оказываются откровением для другого.
По многочисленным просьбам будет продолжение этой статьи (практическая часть) с большим количеством примеров и пошаговыми инструкциями «как начать писать тесты».
Вас заставляют читать эту статью? Почему вы считаете, что JetBrains лично вам чем-то обязан? У меня не возникает вопросов, например, почему я использую YouTrack в своей работе: потому-что в нем все легко, быстро и понятно. К тому же есть бесплатная версия.
Я имел в виду нечто иное. При правильном подходе к написанию автоматизированных тестов количество багов в каждом новом релизе должно снижаться. Раз вы меньше тратите время на исправление багов, у вас больше времени на новые фичи. Все просто.
Немаловажный момент то, что тесты позволяют выловить баг, порой, до попадания кода в VCS. «Цена» исправления, в таком случае, гораздо ниже, чем при хот-патчах на продакшне с последующими мержами в основную ветку разработки.
Баги не кончатся, но наша задача не искоренить все баги. Задача — минимизировать количество ошибок и регрессии в основных юз-кейсай нашего приложения. Это вполне посильная задача.
Это зависит от того вашего стиля работы. Под очень простым кодом я понимаю гетеры, сетеры, экшны контроллеров вида return View(). Если во время делать рефакторинг, простой код остается простым. Если по каким-то причинам он становится сложнее, вы же можете сразу написать тест на этот «усложнившийся» участок.
Я думаю, что вопрос покрытия следует решать индивидуально каждой команде. Нужно пробовать и выбирать то, что работает для вас, а не то «что доктор прописал». А про «красивую» цифру 100% — это вы абсолютно верно подметили.
Вы, видимо, не читали статьи. Сеттеры можно оставить в реализации, а работать по интерфейсу, в котором сеттера не будет, зависимости можно внедрить через конструктор. Если ваши объекты инстанцируются через фабрику или IOC-контейнер до конструктора вы тоже не дотянитесь.
Черный ход здесь не при чем. Качество кода ради тестируемости на падает, а улучшается, т.к. тестируемый код подразуевает слабую связь компонентов.
Страустрап в своей книге о C++ предлагает следующий подход к ООП в целом: если «это» действие — сделайте метод. Если несколько действий объединены общим смыслом и/или процессом — объявите класс. Если придерживаться этого правила, то автоматом класс будет модулем вашего приложения.
Внешняя зависимость — это все, что делает ваши тесты не правдивыми и сложно-поддерживаем. Файловая система — зависимость: структура каталогов может быть другой на другой машине. БД — зависимость, ее может не быть на другой машине. Веб-сервис — зависимость: может не быть интернета или может быть злобный фаервол, а сервис, вообще может взять и упасть, скажем, от Хабра-эффекта.
Спросите себя: «будет ли этот компонент вести себя так же на другой машине?». Если ответ «нет»: нужно его подменить. Если ответ «да» — оставьте его.
Некоторые разработчики начинают увлекаться подменой сущностей и приходят к тому, что подменяют вообще все. Они перестают тестировать приложение и начинают тестировать свои стабы, моки. Это в корне не верно. Если «живых» реализаций в тесте нет, то этот тест не тестирует ничего.
Существует перегиб в обратную сторону. В readme NHibernate'а, не знаю, как сейчас, в прошлых релизах был пункт «пожалуйста, не тестируйте NHibernate, у нас есть свои тесты. Тестируйте вашу бизнес-логику».
Уточняем про перпендикулярность: 7 перпендикулярных любой стороне листа линий (т.е. 7 параллельных). Вносим коррективы: 2 линии должны быть зеленого цвета, две — нанесены прозрачным выпуклым гелем. остальные — красные. Скорее всего заказчик этого и хотел, но идиоты из видео «так поняли» и «так записали» требования.
А надуть шарик — вообще легко: такса $100 в час + оплата командировочных. Т.к. я не специалист в надувании шариков, это займет рабочий день.
И да, почему бы не нарисовать котенка слева снизу.
В разработке действительно больших и сложных систем нет серебряных пуль. А вопросы когда лучше докупить сервер, а когда заняться оптимизацией вообще каждый раз решаются отдельно, и далеко не всегда понятно, что окажется рентабельнее в долгосрочном плане.
Немаловажный момент то, что тесты позволяют выловить баг, порой, до попадания кода в VCS. «Цена» исправления, в таком случае, гораздо ниже, чем при хот-патчах на продакшне с последующими мержами в основную ветку разработки.
Баги не кончатся, но наша задача не искоренить все баги. Задача — минимизировать количество ошибок и регрессии в основных юз-кейсай нашего приложения. Это вполне посильная задача.
Я думаю, что вопрос покрытия следует решать индивидуально каждой команде. Нужно пробовать и выбирать то, что работает для вас, а не то «что доктор прописал». А про «красивую» цифру 100% — это вы абсолютно верно подметили.
Черный ход здесь не при чем. Качество кода ради тестируемости на падает, а улучшается, т.к. тестируемый код подразуевает слабую связь компонентов.
Внешняя зависимость — это все, что делает ваши тесты не правдивыми и сложно-поддерживаем. Файловая система — зависимость: структура каталогов может быть другой на другой машине. БД — зависимость, ее может не быть на другой машине. Веб-сервис — зависимость: может не быть интернета или может быть злобный фаервол, а сервис, вообще может взять и упасть, скажем, от Хабра-эффекта.
Спросите себя: «будет ли этот компонент вести себя так же на другой машине?». Если ответ «нет»: нужно его подменить. Если ответ «да» — оставьте его.
Некоторые разработчики начинают увлекаться подменой сущностей и приходят к тому, что подменяют вообще все. Они перестают тестировать приложение и начинают тестировать свои стабы, моки. Это в корне не верно. Если «живых» реализаций в тесте нет, то этот тест не тестирует ничего.
Существует перегиб в обратную сторону. В readme NHibernate'а, не знаю, как сейчас, в прошлых релизах был пункт «пожалуйста, не тестируйте NHibernate, у нас есть свои тесты. Тестируйте вашу бизнес-логику».