Сообщение Re[24]: Про путаницу с репозиториями и DAO от 30.06.2016 22:26
Изменено 30.06.2016 22:28 another_coder
Здравствуйте, gandjustas, Вы писали:
_>>2) buildQuery(evt) необходимо передать другой сущности, которая занимается его построением. Тогда:
_>>- можно будет отдельно протестировать
_>>- как следствие, можно будет замокать в тестах
_>>Например, вынесем в другой class QueryBuilder : IQueryBuilder {}
G>Зачем? Это чистая функция, её протестировать можно и так. Но тест этот ничего не дает без отправки запроса в базу.
Её конечно можно протестировать. Через вызов Application.Run например тоже можно протестироват её же. И еще кучу других.
Но зачем так усложнять, если можно сделать проще? Выгода: проще понять код, легче модифицировать/выкинуть, в тестах пример использования.
А вопрос и про что дает ниже...
_>>3) В этом случае на метод F можно написать такие юнит тесты (проверяем ветви алгоритма):
_>>- должен возвращать false, если rs.Count>0
_>>- должен возвращать true, если rs.Count<=0
_>>- должен вызвать addEvent с переданным evt, если rs.Count<=0
G>Тестировать if — это сильно.
IF часть часть алгоритма, поэтому необходимо. Вы еще скажите, например, что расчет факториала можно проверить только одним тестом.
_>>4) Отдельно можно протестировать генерацию запросов в методе buildQuery класса QueryBuilder. Не знаю деталей, но девелопер же написал алгоритм генерации, значит может, подавая на вход разные evt, проверить построение соответствующих для них строк. Получится несколько юнит тестов.
G>Само по себе это тестирование ничего не дает. Запросто может просто название поля поменяться.
Именно, что дает. Ваш метод генерилка ни что иное, как y = F(x). x и y определены, а девелопер пишет F. Зачем y отправлять в базу, если это часть требований?
С полем все просто: это часть требований. Поменялись требования к методу, необходимо это отразить в коде.
_>>5) Я полагаю, что в db.query только сам механизм вызова БД. Поэтому, в интеграционном тесте проверяем, что переданный запрос в db.query вернул то, что требовалось запросом. Этот тест покажет, что этот метод получает данные из базы и адекватно выполняет запросы, что и требуется.
G>db — внешний код его тестировать не надо.
У вас был тест на Save в описанном вами случае? Полагаю, с таким тестом вы не пропустили бы проблему им легко нашли бы её.
Главная идея тестов: разбиение кода по принципу SRP, определение требований к полученым кускам и кодирование этих требований в виде UT, IT и пр. Тесты меняются, выкидываются, пишутся новые — не надо этого ояться. TDD форева! )
оффтоп: по вашим коментам выглядит так, словно девелоперы у вас пишут "во тьме": без требований, без понимания того, как оно должно быть. Такое возможно, напрмиер в R&D и там тесты реально не всегда столь эфективны, иногда даже пустая трата времени. Но на то это и исследование/прототипирование.
_>>2) buildQuery(evt) необходимо передать другой сущности, которая занимается его построением. Тогда:
_>>- можно будет отдельно протестировать
_>>- как следствие, можно будет замокать в тестах
_>>Например, вынесем в другой class QueryBuilder : IQueryBuilder {}
G>Зачем? Это чистая функция, её протестировать можно и так. Но тест этот ничего не дает без отправки запроса в базу.
Её конечно можно протестировать. Через вызов Application.Run например тоже можно протестироват её же. И еще кучу других.
Но зачем так усложнять, если можно сделать проще? Выгода: проще понять код, легче модифицировать/выкинуть, в тестах пример использования.
А вопрос и про что дает ниже...
_>>3) В этом случае на метод F можно написать такие юнит тесты (проверяем ветви алгоритма):
_>>- должен возвращать false, если rs.Count>0
_>>- должен возвращать true, если rs.Count<=0
_>>- должен вызвать addEvent с переданным evt, если rs.Count<=0
G>Тестировать if — это сильно.
IF часть часть алгоритма, поэтому необходимо. Вы еще скажите, например, что расчет факториала можно проверить только одним тестом.
_>>4) Отдельно можно протестировать генерацию запросов в методе buildQuery класса QueryBuilder. Не знаю деталей, но девелопер же написал алгоритм генерации, значит может, подавая на вход разные evt, проверить построение соответствующих для них строк. Получится несколько юнит тестов.
G>Само по себе это тестирование ничего не дает. Запросто может просто название поля поменяться.
Именно, что дает. Ваш метод генерилка ни что иное, как y = F(x). x и y определены, а девелопер пишет F. Зачем y отправлять в базу, если это часть требований?
С полем все просто: это часть требований. Поменялись требования к методу, необходимо это отразить в коде.
_>>5) Я полагаю, что в db.query только сам механизм вызова БД. Поэтому, в интеграционном тесте проверяем, что переданный запрос в db.query вернул то, что требовалось запросом. Этот тест покажет, что этот метод получает данные из базы и адекватно выполняет запросы, что и требуется.
G>db — внешний код его тестировать не надо.
У вас был тест на Save в описанном вами случае? Полагаю, с таким тестом вы не пропустили бы проблему им легко нашли бы её.
Главная идея тестов: разбиение кода по принципу SRP, определение требований к полученым кускам и кодирование этих требований в виде UT, IT и пр. Тесты меняются, выкидываются, пишутся новые — не надо этого ояться. TDD форева! )
оффтоп: по вашим коментам выглядит так, словно девелоперы у вас пишут "во тьме": без требований, без понимания того, как оно должно быть. Такое возможно, напрмиер в R&D и там тесты реально не всегда столь эфективны, иногда даже пустая трата времени. Но на то это и исследование/прототипирование.
Здравствуйте, gandjustas, Вы писали:
_>>2) buildQuery(evt) необходимо передать другой сущности, которая занимается его построением. Тогда:
_>>- можно будет отдельно протестировать
_>>- как следствие, можно будет замокать в тестах
_>>Например, вынесем в другой class QueryBuilder : IQueryBuilder {}
G>Зачем? Это чистая функция, её протестировать можно и так. Но тест этот ничего не дает без отправки запроса в базу.
Её конечно можно протестировать. Через вызов Application.Run например тоже можно протестироват её же. И еще кучу других.
Но зачем так усложнять, если можно сделать проще? Выгода: проще понять код, легче модифицировать/выкинуть, в тестах пример использования.
А вопрос про базу и про что дает ниже...
_>>3) В этом случае на метод F можно написать такие юнит тесты (проверяем ветви алгоритма):
_>>- должен возвращать false, если rs.Count>0
_>>- должен возвращать true, если rs.Count<=0
_>>- должен вызвать addEvent с переданным evt, если rs.Count<=0
G>Тестировать if — это сильно.
IF часть алгоритма, поэтому необходимо. Вы еще скажите, например, что расчет факториала можно проверить только одним тестом.
_>>4) Отдельно можно протестировать генерацию запросов в методе buildQuery класса QueryBuilder. Не знаю деталей, но девелопер же написал алгоритм генерации, значит может, подавая на вход разные evt, проверить построение соответствующих для них строк. Получится несколько юнит тестов.
G>Само по себе это тестирование ничего не дает. Запросто может просто название поля поменяться.
Именно, что дает. Ваш метод генерилка ни что иное, как y = F(x). x и y определены, а девелопер пишет F. Зачем y отправлять в базу, если это часть требований?
С полем все просто: это часть требований. Поменялись требования к методу, необходимо это отразить в коде.
_>>5) Я полагаю, что в db.query только сам механизм вызова БД. Поэтому, в интеграционном тесте проверяем, что переданный запрос в db.query вернул то, что требовалось запросом. Этот тест покажет, что этот метод получает данные из базы и адекватно выполняет запросы, что и требуется.
G>db — внешний код его тестировать не надо.
У вас был тест на Save в описанном вами случае? Полагаю, с таким тестом вы не пропустили бы проблему им легко нашли бы её.
Главная идея тестов: разбиение кода по принципу SRP, определение требований к полученым кускам и кодирование этих требований в виде UT, IT и пр. Тесты меняются, выкидываются, пишутся новые — не надо этого ояться. TDD форева! )
оффтоп: по вашим коментам выглядит так, словно девелоперы у вас пишут "во тьме": без требований, без понимания того, как оно должно быть. Такое возможно, напрмиер в R&D и там тесты реально не всегда столь эфективны, иногда даже пустая трата времени. Но на то это и исследование/прототипирование.
_>>2) buildQuery(evt) необходимо передать другой сущности, которая занимается его построением. Тогда:
_>>- можно будет отдельно протестировать
_>>- как следствие, можно будет замокать в тестах
_>>Например, вынесем в другой class QueryBuilder : IQueryBuilder {}
G>Зачем? Это чистая функция, её протестировать можно и так. Но тест этот ничего не дает без отправки запроса в базу.
Её конечно можно протестировать. Через вызов Application.Run например тоже можно протестироват её же. И еще кучу других.
Но зачем так усложнять, если можно сделать проще? Выгода: проще понять код, легче модифицировать/выкинуть, в тестах пример использования.
А вопрос про базу и про что дает ниже...
_>>3) В этом случае на метод F можно написать такие юнит тесты (проверяем ветви алгоритма):
_>>- должен возвращать false, если rs.Count>0
_>>- должен возвращать true, если rs.Count<=0
_>>- должен вызвать addEvent с переданным evt, если rs.Count<=0
G>Тестировать if — это сильно.
IF часть алгоритма, поэтому необходимо. Вы еще скажите, например, что расчет факториала можно проверить только одним тестом.
_>>4) Отдельно можно протестировать генерацию запросов в методе buildQuery класса QueryBuilder. Не знаю деталей, но девелопер же написал алгоритм генерации, значит может, подавая на вход разные evt, проверить построение соответствующих для них строк. Получится несколько юнит тестов.
G>Само по себе это тестирование ничего не дает. Запросто может просто название поля поменяться.
Именно, что дает. Ваш метод генерилка ни что иное, как y = F(x). x и y определены, а девелопер пишет F. Зачем y отправлять в базу, если это часть требований?
С полем все просто: это часть требований. Поменялись требования к методу, необходимо это отразить в коде.
_>>5) Я полагаю, что в db.query только сам механизм вызова БД. Поэтому, в интеграционном тесте проверяем, что переданный запрос в db.query вернул то, что требовалось запросом. Этот тест покажет, что этот метод получает данные из базы и адекватно выполняет запросы, что и требуется.
G>db — внешний код его тестировать не надо.
У вас был тест на Save в описанном вами случае? Полагаю, с таким тестом вы не пропустили бы проблему им легко нашли бы её.
Главная идея тестов: разбиение кода по принципу SRP, определение требований к полученым кускам и кодирование этих требований в виде UT, IT и пр. Тесты меняются, выкидываются, пишутся новые — не надо этого ояться. TDD форева! )
оффтоп: по вашим коментам выглядит так, словно девелоперы у вас пишут "во тьме": без требований, без понимания того, как оно должно быть. Такое возможно, напрмиер в R&D и там тесты реально не всегда столь эфективны, иногда даже пустая трата времени. Но на то это и исследование/прототипирование.