Действительно, в проектах оценка может проводиться в несколько этапов: - есть первоначальная оценка, когда заказчик хочет просто узнать сколько будет стоить. В этом случае, вкладываться в детальную оценку и составлять подробную дорожную карту нет смысла. Заказчик просто приценивается, поэтому и количество трудозатрат должно быть соответствующим. - есть оценка фичи, когда уже есть заказ от заказчика, есть требования и нужно сделать оценку, чтобы сообщить заказчику, когда ориентировочно получит свою фичу. Здесь можно оценку сделать уже более детальную, чем в первый раз. - есть оценка конкретной задачи, когда уже фича в работе. Вот здесь как раз и нужно прям детально фиксировать и разбивать задачу на подзадачи, которые представляют собой маршрут её решения.
Поэтому считаю, что трудозатраты по оценке должны быть соразмерными с этапом проекта. Другими словами, детализация дорожной карты зависит от того насколько близко она к началу реальных работ.
Честно признаюсь, что использование contract coverage не встречал ни на одном проекте из которых мне доводилось работать. Но опыт работы на этих проектах показал, что все понимают важность использования автоматизированных средств контроля качества, но по приоритету такие активности очень часто стоят в конце списка, и они долго пылятся в бэклоге. Судя по вашему комментарию, на вашем проекте иная ситуация и очень рад, что у вас на проекте есть ресурсы для внедрения таких инструментов и поддержки их.
Широко использовал во многих проектах аннотацию `@Sql`. Но я столкнулись с проблемой при использовании такого решения: сложно поддерживать sql запросы, которые кодируются текстом. Для себя я выявил следующие недостатки такого подхода: - сложно переиспользовать sql запросы - сложно кастомизировать sql запросы с помощью параметров - при частом изменении схемы править приходится большое количество sql запросов - не очевиден порядок выполнения sql запросов - необходимо в insert sql запросе обязательно указывать все not null значения, что в итоге приводит к не пониманию, а какие именно значения нужны для теста - как бы странно не звучало, не все проекты написаны на Spring Framework
Я искал решение, которое бы могло покрыть все описанные выше недостатки, но к сожалению не нашёл. Поэтому написал DbChange. Изначально в нём была возможность только задать changeset (через Java классы). Но потом я подумал, что у решения предлагаемого Spring Framework тоже есть плюсы и кому-то это может быть полезным. И потом уже добавил поддержку statements и sqlQueryFiles.
Я намерено в статье не ссылался на Spring Framework, т.к. библиотека не позиционируется как альтернатива его аннотации `@Sql`. Хотя вы верно отметили, что часть функций схожа. Вы можете использовать любую из них или обе сразу. Это ваш выбор. Но в любом случае, спасибо, что обратили на это внимание. На мой взгляд, важно предоставить разработчику набор инструментов, чтобы он уже сам выбрал подходящий для решаемых задач.
К сожалению, не понял вашего вопроса. Поясните, пожалуйста.
Вы подсветили хороший сценарий.
Действительно, в проектах оценка может проводиться в несколько этапов:
- есть первоначальная оценка, когда заказчик хочет просто узнать сколько будет стоить. В этом случае, вкладываться в детальную оценку и составлять подробную дорожную карту нет смысла. Заказчик просто приценивается, поэтому и количество трудозатрат должно быть соответствующим.
- есть оценка фичи, когда уже есть заказ от заказчика, есть требования и нужно сделать оценку, чтобы сообщить заказчику, когда ориентировочно получит свою фичу. Здесь можно оценку сделать уже более детальную, чем в первый раз.
- есть оценка конкретной задачи, когда уже фича в работе. Вот здесь как раз и нужно прям детально фиксировать и разбивать задачу на подзадачи, которые представляют собой маршрут её решения.
Поэтому считаю, что трудозатраты по оценке должны быть соразмерными с этапом проекта. Другими словами, детализация дорожной карты зависит от того насколько близко она к началу реальных работ.
Честно признаюсь, что использование contract coverage не встречал ни на одном проекте из которых мне доводилось работать. Но опыт работы на этих проектах показал, что все понимают важность использования автоматизированных средств контроля качества, но по приоритету такие активности очень часто стоят в конце списка, и они долго пылятся в бэклоге. Судя по вашему комментарию, на вашем проекте иная ситуация и очень рад, что у вас на проекте есть ресурсы для внедрения таких инструментов и поддержки их.
Спасибо за статью! Примеры в официальной документации похоже давно устарели. Приятно найти актуальное на текущий день руководство.
Широко использовал во многих проектах аннотацию `@Sql`. Но я столкнулись с проблемой при использовании такого решения: сложно поддерживать sql запросы, которые кодируются текстом. Для себя я выявил следующие недостатки такого подхода:
- сложно переиспользовать sql запросы
- сложно кастомизировать sql запросы с помощью параметров
- при частом изменении схемы править приходится большое количество sql запросов
- не очевиден порядок выполнения sql запросов
- необходимо в insert sql запросе обязательно указывать все not null значения, что в итоге приводит к не пониманию, а какие именно значения нужны для теста
- как бы странно не звучало, не все проекты написаны на Spring Framework
Я искал решение, которое бы могло покрыть все описанные выше недостатки, но к сожалению не нашёл. Поэтому написал DbChange. Изначально в нём была возможность только задать changeset (через Java классы). Но потом я подумал, что у решения предлагаемого Spring Framework тоже есть плюсы и кому-то это может быть полезным. И потом уже добавил поддержку statements и sqlQueryFiles.
Я намерено в статье не ссылался на Spring Framework, т.к. библиотека не позиционируется как альтернатива его аннотации `@Sql`. Хотя вы верно отметили, что часть функций схожа. Вы можете использовать любую из них или обе сразу. Это ваш выбор. Но в любом случае, спасибо, что обратили на это внимание. На мой взгляд, важно предоставить разработчику набор инструментов, чтобы он уже сам выбрал подходящий для решаемых задач.
Согласен, скачивание из Maven Central, гораздо удобнее и привычнее для Java разработчика.
Спасибо за ваш комментарий. Дополню статью об использовании TestInfo.
Спасибо за ваше мнение. Согласен, взглядов много и мой всего лишь один из многих.