Согласны про больше интеграционных. Мы тут под Unit подразумеваем не всегда самую маленькую и ни от чего независящую единицу. Мы сейчас тоже перешли к большему количеству интеграционных тестов + минимум E2E-тестов самого API, которые заменяют каноничные Unit-тесты..
А у нас достаточно опыта в .NET и насмотренности в других стеках, таких как Python, NodeJS, C/C++. Один из авторов, который вам сейчас пишет - Александр, начинал профессиональную карьеру на C# 13 лет назад, читал Рихтера, Фаулера, Мартина и т.д., делал проекты, ездил учиться на конференции DotNext, а сейчас и сам делится знаниями и видением.
Для нас так стало проще и интереснее, и веселее :)
В отдельной статье поделимся тем, как именно пишем тесты на бекенды, напсанные на .NET, на каких слоях пирамиды тестирования, используя какие инструменты и подходы.
Здесь хотели поделиться идеей, её плюсами и техническими деталями реализации.
Классный совет! Спасибо, мы попробуем :) 12 лет назад пользовались Razor и Web.config со всеми их скрытыми вложенностями, что-то не подумали, что такая фича всё ещё должна быть и прикольно работать.
Интересный вопрос: сделает эта штука Development Experience лучше или нет. В том плане, что надо будет расхлопнуть файл, чтобы увидеть, что к нему есть привязанный тест, по этой причине также не любим регионы, куда прячутся портянки кода. С другой стороны, это компактнее.
Вы правы, для чувствительных данных, таких как логин, пароль от базы данных, нужно использовать как минимум env переменные. Не добавили этого в статью, чтобы не усложнять пример. Чтобы попробовать фичи - достаточно скопировать и вставить, без создания переменных, откуда будут браться логины и пароли. Что насчет портов: мы указали порт для базы данных, чтобы иметь возможность подключиться к ней из API, запущенного в IDE. Спасибо за совет, посмотрим в сторону бинда на локальный хост :)
Да, отличная идея добавить healthcheck. Мы используем эту фичу в наших других проектах, но для простоты примера не добавили её в статье, чтобы сфокусироваться на представленных выше фичах. Спасибо за совет!
Да, вы правы, можно использовать внешнюю переменную окружения. Но мы выбрали этот кейс как простой пример использования шаблонов сервисов. Нам, например, может понадобиться изменить скрипт в одном из копий сервиса, и для того, чтобы не копировать весь сервис, используем шаблон Спасибо за совет о docker compose, учтем!
Можно поставить любые расширения в связке ide+docker-compose, но тогда их либо придется ставить внутрь контейнера + vs code туда же, либо, если использовать docker-compose чисто для сборки и билда, расширения придется ставить локально. Dev контейнеры же легко позволяют устанавливать расширения именно в контейнер.
Зависит от того, что вам нужно. Мы, например, используем расширения VS Code для поддержки синтаксиса языка, для удобного взаимодействия с Cmake, для написания документации и поддержки Mermaid и многие другие. Удобно, когда нужное расширение одним кликом можно добавить в контейнер.
Конечно, можно. Но зачем, если в dev контейнерах это уже автоматизировано? Что нужно делать с docker-compose: прокидывать volume с хоста, устанавливать расширения, настраивать IDE в контейнере. Что нужно сделать с dev контейнером: кликнуть на кнопку.
Это немного разные технологии с разным фокусом: docker compose – средство для запуска и управления контейнерами, dev containers – средство для контейнерной разработки. Да, можно настроить контейнер через docker compose и использовать его для контейнерной разработки, но это будет сложнее. Dev контейнеры уже интегрированы в среду разработки, их использовать проще.
Очень справедливое замечание про шаблоны. Мы используем шаблон компании, однако даже тут порой возникают сложности, если информация на слайде не подходит под шаблон. Примеры из статьи не претендуют на окончательный вариант дизайна презентации, а больше иллюстрируют содержание статьи. Наши рекомендации помогают нам на крупных российских конференциях. Надеемся, кому-то они тоже смогут помочь.
Приветствуем, Юпитер. Вы правы, существует еще множество полезных советов по подготовке хорошей презентации, в том числе не связанных с ее оформлением. Может быть, мы расскажем о них в следующей статье;)
Как раз хороший пример консистентности. У примера с черепахоенотами уникальная и более подходящая для этого конкретного случая композиция, в то же время он не выбивается из общего стиля и согласован с другими примерами.
У нас стенд стоит в офисе, и в нем нет никаких кулеров, на процессоре, например, просто стоит большой радиатор. Так сервер не издает никакого шума и не мешает тем, кто находится с ним рядом. Когда выбирали видеокарту, опирались на кол-во видеопамяти, а также на то, насколько она шумная, вот почему выбор пал на теслу. Но как оказалось просто радиатора недостаточно для охлаждения видеокарты.
Спасибо вам за интересное мнение! Хотелось бы немного порассуждать на эту тему.
Прежде всего, я считаю, что отсутствие сроков может негативно сказаться на проекте, приводя к постоянным доработкам, желанию добавить новый функционал или дополировать уже готовый и, в результате, к бесконечному растягиванию времени выполнения проекта. Как мне кажется, сроки устанавливают определенные рамки, в которые необходимо вписываться, и помогают избежать бесконечных доработок.
Из этого вытекает следующий важный момент. Чем дольше проект находится в работе, тем выше вероятность, что он утратит свою актуальность, станет ненужным и не будет соответствовать быстро развивающимся технологиям.
Также мне кажется, что отсутствие предварительных сроков сильно ограничивает возможность планирования. Как для заказчика, который хочет знать, когда получит готовый продукт, и спланировать дальнейшие действия. Так и для исполнителя, который может работать над несколькими проектами, каждый из которых требует грамотного планирования и внимания. Еще оценка помогает определить приблизительные затраты на проект (если это не фикс прайс, конечно). На мой взгляд, для заказчика важно иметь представление о приблизительной стоимости проекта. Без возможности спланировать сразу и время, и приблизительный бюджет проекта заказчику будет трудновато.
Как вы верно отметили, у некоторых клиентов могут быть слишком оптимистичные и завышенные ожидания, поскольку они не всегда осознают объем работы. По моему мнению, если мы не будем занижать эти ожидания в процессе обсуждения проекта, существует бóльшая вероятность столкнуться с тем, что заказчика не устроит скорость работы. В таком случае, часть работы будет проделана, а оставшаяся часть будет доделываться с большим напряжением из-за обманутых ожиданий. Объясняя оценку и занижая ожидания, мы заранее готовим заказчика к реальному времени выполнения проекта, он ментально настраивается на это и это помогает избежать неправильных представлений о сроках и разочарований.
Ну и наконец, как мне кажется, важно помнить, что это заказчик обращается за услугой, а не наоборот. Если бы я, как клиент, обратилась за услугой в другой сфере и по срокам мне бы ответили: "Будет готово, когда мы закончим", я вряд ли бы стала обращаться снова к этому исполнителю. Всё-таки в наших интересах установить хорошие отношения с клиентом, оправдать его ожидания и принести пользу.
“Если бы все из IT сферы ит.п придерживались этого правила, то не было бы этих ненормальных дедлайнов и горе руководителей/клиентов”. На мой взгляд, горе руководители всегда найдут, над чем охать и ахать. Опять же это ответственность исполнителя установить контакт с клиентом, создать комфортный процесс работы и сделать все возможное, чтобы не допустить для себя “ненормальных дедлайнов” и жуткого стресса. В конце концов, если уже на первоначальном этапе не удается установить нормальный диалог с клиентом, можно отказаться от совместной работы.
Было бы крайне интересно узнать ваше мнение относительно этих рассуждений:)
Согласны про больше интеграционных. Мы тут под Unit подразумеваем не всегда самую маленькую и ни от чего независящую единицу. Мы сейчас тоже перешли к большему количеству интеграционных тестов + минимум E2E-тестов самого API, которые заменяют каноничные Unit-тесты..
А у нас достаточно опыта в .NET и насмотренности в других стеках, таких как Python, NodeJS, C/C++. Один из авторов, который вам сейчас пишет - Александр, начинал профессиональную карьеру на C# 13 лет назад, читал Рихтера, Фаулера, Мартина и т.д., делал проекты, ездил учиться на конференции DotNext, а сейчас и сам делится знаниями и видением.
Ещё ребята в Go так делают: https://go.dev/doc/tutorial/add-a-test и вот ещё интересное обсуждение такого подхода, https://www.reddit.com/r/golang/comments/157tsdj/where_do_you_place_your_tests_in_your_project/?rdt=51749.
Если что, мы ещё и не верим в автомаппер и медиатор в .NET проектах =ъ
Пыс: не очень понятно откуда и зачем такой негатив
Проверили, работает, спасибо, будем знать :)
Для нас так стало проще и интереснее, и веселее :)
В отдельной статье поделимся тем, как именно пишем тесты на бекенды, напсанные на .NET, на каких слоях пирамиды тестирования, используя какие инструменты и подходы.
Здесь хотели поделиться идеей, её плюсами и техническими деталями реализации.
Классный совет! Спасибо, мы попробуем :) 12 лет назад пользовались Razor и Web.config со всеми их скрытыми вложенностями, что-то не подумали, что такая фича всё ещё должна быть и прикольно работать.
Интересный вопрос: сделает эта штука Development Experience лучше или нет. В том плане, что надо будет расхлопнуть файл, чтобы увидеть, что к нему есть привязанный тест, по этой причине также не любим регионы, куда прячутся портянки кода. С другой стороны, это компактнее.
Будем пробовать и смотреть, как пошло.
Вы правы, для чувствительных данных, таких как логин, пароль от базы данных, нужно использовать как минимум env переменные. Не добавили этого в статью, чтобы не усложнять пример. Чтобы попробовать фичи - достаточно скопировать и вставить, без создания переменных, откуда будут браться логины и пароли.
Что насчет портов: мы указали порт для базы данных, чтобы иметь возможность подключиться к ней из API, запущенного в IDE. Спасибо за совет, посмотрим в сторону бинда на локальный хост :)
Да, отличная идея добавить healthcheck. Мы используем эту фичу в наших других проектах, но для простоты примера не добавили её в статье, чтобы сфокусироваться на представленных выше фичах. Спасибо за совет!
Спасибо, узнали что-то новое, исправим!
Да, вы правы, можно использовать внешнюю переменную окружения. Но мы выбрали этот кейс как простой пример использования шаблонов сервисов. Нам, например, может понадобиться изменить скрипт в одном из копий сервиса, и для того, чтобы не копировать весь сервис, используем шаблон
Спасибо за совет о docker compose, учтем!
Да, действительно используем docker desktop. Посмотрим в сторону rancher desktop, спасибо :)
Можно поставить любые расширения в связке ide+docker-compose, но тогда их либо придется ставить внутрь контейнера + vs code туда же, либо, если использовать docker-compose чисто для сборки и билда, расширения придется ставить локально. Dev контейнеры же легко позволяют устанавливать расширения именно в контейнер.
Зависит от того, что вам нужно. Мы, например, используем расширения VS Code для поддержки синтаксиса языка, для удобного взаимодействия с Cmake, для написания документации и поддержки Mermaid и многие другие. Удобно, когда нужное расширение одним кликом можно добавить в контейнер.
Конечно, можно. Но зачем, если в dev контейнерах это уже автоматизировано?
Что нужно делать с docker-compose: прокидывать volume с хоста, устанавливать расширения, настраивать IDE в контейнере.
Что нужно сделать с dev контейнером: кликнуть на кнопку.
Это немного разные технологии с разным фокусом: docker compose – средство для запуска и управления контейнерами, dev containers – средство для контейнерной разработки. Да, можно настроить контейнер через docker compose и использовать его для контейнерной разработки, но это будет сложнее. Dev контейнеры уже интегрированы в среду разработки, их использовать проще.
Очень справедливое замечание про шаблоны. Мы используем шаблон компании, однако даже тут порой возникают сложности, если информация на слайде не подходит под шаблон. Примеры из статьи не претендуют на окончательный вариант дизайна презентации, а больше иллюстрируют содержание статьи. Наши рекомендации помогают нам на крупных российских конференциях. Надеемся, кому-то они тоже смогут помочь.
Приветствуем, Юпитер. Вы правы, существует еще множество полезных советов по подготовке хорошей презентации, в том числе не связанных с ее оформлением. Может быть, мы расскажем о них в следующей статье;)
Как раз хороший пример консистентности. У примера с черепахоенотами уникальная и более подходящая для этого конкретного случая композиция, в то же время он не выбивается из общего стиля и согласован с другими примерами.
У нас стенд стоит в офисе, и в нем нет никаких кулеров, на процессоре, например, просто стоит большой радиатор. Так сервер не издает никакого шума и не мешает тем, кто находится с ним рядом. Когда выбирали видеокарту, опирались на кол-во видеопамяти, а также на то, насколько она шумная, вот почему выбор пал на теслу. Но как оказалось просто радиатора недостаточно для охлаждения видеокарты.
Спасибо вам за интересное мнение! Хотелось бы немного порассуждать на эту тему.
Прежде всего, я считаю, что отсутствие сроков может негативно сказаться на проекте, приводя к постоянным доработкам, желанию добавить новый функционал или дополировать уже готовый и, в результате, к бесконечному растягиванию времени выполнения проекта. Как мне кажется, сроки устанавливают определенные рамки, в которые необходимо вписываться, и помогают избежать бесконечных доработок.
Из этого вытекает следующий важный момент. Чем дольше проект находится в работе, тем выше вероятность, что он утратит свою актуальность, станет ненужным и не будет соответствовать быстро развивающимся технологиям.
Также мне кажется, что отсутствие предварительных сроков сильно ограничивает возможность планирования. Как для заказчика, который хочет знать, когда получит готовый продукт, и спланировать дальнейшие действия. Так и для исполнителя, который может работать над несколькими проектами, каждый из которых требует грамотного планирования и внимания. Еще оценка помогает определить приблизительные затраты на проект (если это не фикс прайс, конечно). На мой взгляд, для заказчика важно иметь представление о приблизительной стоимости проекта. Без возможности спланировать сразу и время, и приблизительный бюджет проекта заказчику будет трудновато.
Как вы верно отметили, у некоторых клиентов могут быть слишком оптимистичные и завышенные ожидания, поскольку они не всегда осознают объем работы. По моему мнению, если мы не будем занижать эти ожидания в процессе обсуждения проекта, существует бóльшая вероятность столкнуться с тем, что заказчика не устроит скорость работы. В таком случае, часть работы будет проделана, а оставшаяся часть будет доделываться с большим напряжением из-за обманутых ожиданий. Объясняя оценку и занижая ожидания, мы заранее готовим заказчика к реальному времени выполнения проекта, он ментально настраивается на это и это помогает избежать неправильных представлений о сроках и разочарований.
Ну и наконец, как мне кажется, важно помнить, что это заказчик обращается за услугой, а не наоборот. Если бы я, как клиент, обратилась за услугой в другой сфере и по срокам мне бы ответили: "Будет готово, когда мы закончим", я вряд ли бы стала обращаться снова к этому исполнителю. Всё-таки в наших интересах установить хорошие отношения с клиентом, оправдать его ожидания и принести пользу.
“Если бы все из IT сферы ит.п придерживались этого правила, то не было бы этих ненормальных дедлайнов и горе руководителей/клиентов”. На мой взгляд, горе руководители всегда найдут, над чем охать и ахать. Опять же это ответственность исполнителя установить контакт с клиентом, создать комфортный процесс работы и сделать все возможное, чтобы не допустить для себя “ненормальных дедлайнов” и жуткого стресса. В конце концов, если уже на первоначальном этапе не удается установить нормальный диалог с клиентом, можно отказаться от совместной работы.
Было бы крайне интересно узнать ваше мнение относительно этих рассуждений:)
Спасибо за совет! Возьмем на заметку этот метод.