Здравствуйте, Pauel, Вы писали:
P>Ты собираешься все юнит-тесты сделать медленными
Нет, я такого никогда не предлагал. Давай ты просто прежде чем фантазировать перечитаешь то что я писал выше и если у тебя есть какие-то догадки, подкрепляй их _моими_ цитатами.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[19]: Как тестировать серверные сервисные приложения?
Здравствуйте, ·, Вы писали:
P>>Ты собираешься все юнит-тесты сделать медленными ·>Нет, я такого никогда не предлагал. Давай ты просто прежде чем фантазировать перечитаешь то что я писал выше и если у тебя есть какие-то догадки, подкрепляй их _моими_ цитатами.
Ты предлагаешь задачу, которая решается юнит-тестами, вытащить на уровень интеграционных
А это значит, что все приверки мелочевки, коей как грязи в болоте, будут гоняться через, внимание, паттерн вида
dao.saveDocument(doc1);
dao.saveDocument(doc2);
var result = dao.findDocumentsByDate(startDate);
assertThat(result).is(Set.of(doc1));
И тут мы выясням, что ин-мемори дб может и не быть, значит придется гонять через обычную.
Итого — ты решил заменить быстрые юнит-тесты медленными интеграционными.
Результат ожидаем — девелоперы будут стремиться писать такого поменьше.
Re[20]: Как тестировать серверные сервисные приложения?
Здравствуйте, Pauel, Вы писали:
P>>>Ты собираешься все юнит-тесты сделать медленными P>·>Нет, я такого никогда не предлагал. Давай ты просто прежде чем фантазировать перечитаешь то что я писал выше и если у тебя есть какие-то догадки, подкрепляй их _моими_ цитатами. P>Наоборот, читай себя сам http://rsdn.org/forum/apptesting/8429753.1
P>Ты предлагаешь задачу, которая решается юнит-тестами, вытащить на уровень интеграционных
Покажи мне решение этой задачи юнит-тестами. Предложенное выше посимвольное сравнение текста sql-запросов я считаю плохим решением и написал почему.
Более того, я сказал не "вытащить", а тупо выкинуть такие юнит-тесты, т.к. они ничего полезного не делают. Предложенные юнит-тесты никак не отменяют необходимость интеграционных по причинам которые ты даже сам рассказал.
P>А это значит, что все приверки мелочевки, коей как грязи в болоте, будут гоняться через, внимание, паттерн вида
Верно. Будет проверяться логика запроса — что он возвращает для каких данных. А не из каких буковок состоит запрос, проверять буковки — бессмысленно.
P>И тут мы выясням, что ин-мемори дб может и не быть, значит придется гонять через обычную.
Это не проблема, и я привёл в пример h2db, которая может притворяться разными dbms. Вдобавок, тот же psql можно тупо запускать локально. Если его специальным образом подкрутить для таких запусков, то и in-mem в общем-то совсем не нужен станет.
P>Итого — ты решил заменить быстрые юнит-тесты медленными интеграционными.
Нет. Я предложил выкинуть такие юнит-тесты. И, если это проблема, ускорить локальный запуск интеграционных — я тоже уже рассказал как.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[21]: Как тестировать серверные сервисные приложения?
Здравствуйте, ·, Вы писали:
P>>Ты предлагаешь задачу, которая решается юнит-тестами, вытащить на уровень интеграционных ·>Покажи мне решение этой задачи юнит-тестами. Предложенное выше посимвольное сравнение текста sql-запросов я считаю плохим решением и написал почему.
Это смотря какой клиент к бд. К некоторым будет json, который легко будет сравнивать.
·>Более того, я сказал не "вытащить", а тупо выкинуть такие юнит-тесты, т.к. они ничего полезного не делают. Предложенные юнит-тесты никак не отменяют необходимость интеграционных по причинам которые ты даже сам рассказал.
От интеграционных нам нужна проверка интеграции а не граничных случаев вида "если в фильтр насовали хрензнаетсколькилион признаков, то результат содержит произвольный экземпляр"
P>>А это значит, что все приверки мелочевки, коей как грязи в болоте, будут гоняться через, внимание, паттерн вида ·>Верно. Будет проверяться логика запроса — что он возвращает для каких данных. А не из каких буковок состоит запрос, проверять буковки — бессмысленно.
Наоборот. То есть, гонять ты будешь на небольшом фиксированом клочке и будешь надеяться, что твои фильтры ого-го!
А потом юзер пишет "если больше сотни результатов, то фильтр выдаёт абы что"
P>>Итого — ты решил заменить быстрые юнит-тесты медленными интеграционными. ·>Нет. Я предложил выкинуть такие юнит-тесты. И, если это проблема, ускорить локальный запуск интеграционных — я тоже уже рассказал как.
Выкинуть нельзя — все эти проверки нужно заменить интеграционными тестами.
Re[22]: Как тестировать серверные сервисные приложения?
Здравствуйте, Pauel, Вы писали:
P>>>Ты предлагаешь задачу, которая решается юнит-тестами, вытащить на уровень интеграционных P>·>Покажи мне решение этой задачи юнит-тестами. Предложенное выше посимвольное сравнение текста sql-запросов я считаю плохим решением и написал почему. P>Это смотря какой клиент к бд. К некоторым будет json, который легко будет сравнивать.
Я не смотрел на что попало. Я отвечал на вполне конкретный пример от Sinclair: "Достаточно того, что при задании параметра startDate во where добавляется documentDate >= @startDate, а без него — не добавляется."
Если у тебя конкретные вопросы, задавай, а не придумывай условия задним числом.
P>·>Более того, я сказал не "вытащить", а тупо выкинуть такие юнит-тесты, т.к. они ничего полезного не делают. Предложенные юнит-тесты никак не отменяют необходимость интеграционных по причинам которые ты даже сам рассказал. P>От интеграционных нам нужна проверка интеграции а не граничных случаев вида "если в фильтр насовали хрензнаетсколькилион признаков, то результат содержит произвольный экземпляр"
Это опять твоя неуёмная фантазия. Моим предложением к этому примеру Sinclair было именно проверять что при задании параметра startDate возвращаются именно те документы, которые я ожидаю должны вернуться. Т.е. запрос надо исполнить и проверить, что он выдал то что надо, а не то что закодировано в sql строчке.
Sinclair даже не смог ответить на вопрос как же собственно тупо синтаксис тестового образца sql-запроса проверить. Может ты ответишь?
P>>>А это значит, что все приверки мелочевки, коей как грязи в болоте, будут гоняться через, внимание, паттерн вида P>·>Верно. Будет проверяться логика запроса — что он возвращает для каких данных. А не из каких буковок состоит запрос, проверять буковки — бессмысленно. P>Наоборот. То есть, гонять ты будешь на небольшом фиксированом клочке и будешь надеяться, что твои фильтры ого-го! P>А потом юзер пишет "если больше сотни результатов, то фильтр выдаёт абы что"
Допустим. Как ты это предлагаешь решать юнит-тестами?
P>>>Итого — ты решил заменить быстрые юнит-тесты медленными интеграционными. P>·>Нет. Я предложил выкинуть такие юнит-тесты. И, если это проблема, ускорить локальный запуск интеграционных — я тоже уже рассказал как. P>Выкинуть нельзя — все эти проверки нужно заменить интеграционными тестами.
Никакой замены, интеграционные тесты всё равно нужны, ты же сам мне это доказывал.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
