The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Ценой перевода Mercurial на Python 3 может стать шлейф непре..., opennews (ok), 14-Янв-20, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


15. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  +5 +/
Сообщение от brzm (ok), 14-Янв-20, 23:42 
> так как тесты не охватывают 100% кодовой базы, а многие проблемы незаметны при статическом анализе и проявляются только во время выполнения

Вроде сами признали, по тексту новости сложилось такое впечатление. Может вы что-то знаете чего не знаем мы?

Ответить | Правка | Наверх | Cообщить модератору

30. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  +7 +/
Сообщение от Аноним (30), 15-Янв-20, 00:24 
Механический подсчет покрытия тоже не гарантирует ничего.

Вот, допустим, есть такая функция:

int f(int x, int y) {
  int arr[2] = { 0, 0 };
  int i = 1;

  if (x == 1)
    i--;

  if (y == 1)
    i--;

  return arr[i];
}

Сделали тесты на f(0, 1) и на f(1, 0), test coverage бодро рапортует 100%, а программа падает.

Ответить | Правка | Наверх | Cообщить модератору

35. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  +/
Сообщение от kai3341 (ok), 15-Янв-20, 00:38 
Удваиваю. Покрытие ради покрытия ещё ни о чём не говорит
Особенно грустно, когда тестами покрывается реализация, а не интерфейс (API, а не графический) -- рефакторинг превращается борьбу со сломанными тестами. В результате тесты перестают помогать разработке и вместо этого сковывают -- каждое движение заставляет сделать ещё 100500 правок. Интересно при этом то, что прохождение 100% тестов не гарантирует отсутствие ошибок
Ответить | Правка | Наверх | Cообщить модератору

41. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  +1 +/
Сообщение от Аноним (30), 15-Янв-20, 00:46 
Покрывать тестами надо и то, и другое.
Юнит-тесты хороши для библиотек, реализующих нетривиальные алгоритмы, особенно оптимизированные, когда логику уже не так-то просто проследить. Во время написания алгоритма обычно помнишь о хитрых edge cases, которые надо проверить, а при внесении изменений через несколько лет можно и не вспомнить, особенно если изменения вносит кто-то другой.
Покрывать же юнит-тестами всякую там обвязку - во-первых, сложно, а во-вторых, бессмысленно: обвязка обычно не имеет самостоятельной ценности, а важна вкупе с использующим ее кодом, который может так же легко измениться, и получится бессмысленная работа по поддержанию тестов ради тестов. Важна работа предоставляемого API - и его-то тут и надо тестировать.
Ответить | Правка | Наверх | Cообщить модератору

43. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  –1 +/
Сообщение от kai3341 (ok), 15-Янв-20, 00:50 
В качестве ответа я сошлюсь на Линуса. "Не ломать юзерленд" -- это значит не менять внешние API ядра.
При этом, внутренние API (что есть реализация) могут запросто меняться. По этой причине ядерные блобы в линуксах -- дурной тон.
Ответить | Правка | Наверх | Cообщить модератору

53. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  +/
Сообщение от Аноним (30), 15-Янв-20, 00:59 
А тут я полностью согласен. Но тестами на API сложно покрыть edge cases в алгоритмах (конечному пользователю пофиг, какие там внутри алгоритмы) - потому нужны оба.
Ответить | Правка | Наверх | Cообщить модератору

62. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  –1 +/
Сообщение от kai3341 (ok), 15-Янв-20, 01:09 
>  А тут я полностью согласен. Но тестами на API сложно покрыть edge cases в алгоритмах (конечному пользователю пофиг, какие там внутри алгоритмы) - потому нужны оба.

Очень вероятно, что мы называем одни и те же вещи разными словами. Тест внешнего API включает в себя и проверку результата. Сам алгоритм алгоритму рознь: для чистых функций мы имеем право применять lru_cache, что формально меняет алгоритм. Иногда ради производительности можно пойти на коренные изменения алгоритма: https://ru.wikipedia.org/wiki/%D0%91%D1%...
Наконец, реструктуризация меняет алгоритм, но не должна менять результат

Ответить | Правка | Наверх | Cообщить модератору

70. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  +2 +/
Сообщение от Аноним (30), 15-Янв-20, 01:59 
Тут ещё вопрос, где API. Например, в Solaris был баг в реализации qsort(), который приводил к тому, что для входных массивов с пачкой идущих подряд одинаковых значений сортировка занимала неприлично долгое время. Да, конечно, в quicksort amortized n log n, и worst case n^2, но разница с реализацией из BSD или Linux была на порядок.

В случае с Solaris libc, qsort() - это вроде как API. А если кто-то скопипастил эту же реализацию в свой проект, и использует для сортировки во внутренней реализации - там вроде как юнит-тест нужен, ведь подготовить такой тестовый набор данных "снаружи", на котором эта проблема проявится, может оказаться крайне сложно. Но покрыть тестом один фиг надо.

Ответить | Правка | Наверх | Cообщить модератору

75. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  –1 +/
Сообщение от kai3341 (ok), 15-Янв-20, 02:21 
Принято. Речь о тонкой границе, когда компонент реализации стабилизируется и становится внутренним API -- на него завязываются другие внутренние компоненты приложения.
ИМХО тут важно соблюсти баланс -- если от компонента что-то зависит, должны быть тесты, однако эти же тесты не должны связывать руки, если компонент необходимо подвергнуть модификации. Где именно этот баланс -- я не знаю.
Ответить | Правка | Наверх | Cообщить модератору

221. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  +1 +/
Сообщение от Аноним (221), 15-Янв-20, 14:52 
Вероятно, вы говорите о разных вещах одними словами. И для этих разных вещей придумали разные слова: функциональное и юнит-тестирование.
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

226. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  –1 +/
Сообщение от kai3341 (ok), 15-Янв-20, 15:13 
Спасибо. Учту
Ответить | Правка | Наверх | Cообщить модератору

42. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  +/
Сообщение от Вашье (?), 15-Янв-20, 00:49 
Так вы, это, мутируйте поменьше, и никто никуда падать не будет.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

45. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  +/
Сообщение от Аноним (30), 15-Янв-20, 00:53 
Это тоже ничего не гарантирует. Точно такую же проблему можно показать и на чистых функциях с рекурсией.
Ответить | Правка | Наверх | Cообщить модератору

46. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."  +/
Сообщение от kai3341 (ok), 15-Янв-20, 00:53 
>  Так вы, это, мутируйте поменьше, и никто никуда падать не будет.

Иммутабельность не является гарантией отсутствия ошибок. Иммутабельность не гарантирует отсутствие падений.
Всему своё время и место, включая мутабельность и иммутабельность

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру