?

Log in

No account? Create an account
о тестировании (программистское) - По делам сюда приплыл, а не за этим [entries|archive|friends|userinfo]
Anatoly Vorobey

[ website | Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| English-language weblog ]

о тестировании (программистское) [ноя. 26, 2014|11:50 pm]
Anatoly Vorobey
[Tags|]

Годы работы в Гугле изменили меня кое-где незаметно для меня самого. На днях мне захотелось посмотреть, как обстоят дела в FreeBSD, которой я активно не пользовался лет двенадцать. Установил последнюю версию на сервере, который в сторонке залежался. Установил исходники ядра и юзерленда (svn о боже мой). Посмотрел кое-что, что мне было интересно, в исходниках TCP/IP-стека, и сравнил с линуксовскими исходниками. И вдруг подумал: а если это менять, то где тесты? А тестов-то и нет. Да ладно ядро, у системных утилит тоже нет никаких тестов. И у большинства системных библиотек. Опаньки.

А как жить-то? Как люди живут вообще?

Не то чтобы раньше я не любил и не признавал тестирование, нет, наоборот (я работал много лет на Перле, например, а у Перла была культура тестирования, лет на 6 опередившая другие современные языки). Насколько я помню себя 10 лет назад, у меня было такое отношение, что когда есть тесты, то это хорошо, с ними лучше, чем без них. Теперь у меня скорее другое отношение: если их нет у нетривиального куска кода, то как вообще работать? Нет, если припечет, я смогу конечно, у меня голова соображает. Но это же как передвигаться прыжками со связанными ногами.
СсылкаОтветить

Comments:
From: squadette
2014-11-26 09:59 pm
ммм а Linux как-то принципиально отличается от FreeBSD в этом отношении?
(Ответить) (Thread)
[User Picture]From: avva
2014-11-26 10:05 pm
Ядро точно никак. Юзерланд в целом тоже, хотя местами может быть лучше. У glibc вроде есть большой и серьезный test suite, если память не изменяет.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: dmarck
2014-11-26 10:11 pm
Это движется, надо признать, хотя и очень медленно:

http://jenkins-ci.org/content/freebsd-project-use-jenkins-os-testing

Upd: plus https://wiki.freebsd.org/TestSuite


-- marck@FreeBSD.org ;-P

Edited at 2014-11-26 22:14 (UTC)
(Ответить) (Thread)
[User Picture]From: avva
2014-11-26 10:30 pm
А почему я в дереве вижу кучу мест, где тесты заимствуются тоннами из contrib/netbsd-tests? Что, NetBSD уже по сути дела решила эту проблему?
(Ответить) (Parent) (Thread) (Развернуть)
From: tr1gger
2014-11-26 10:30 pm
Да, не может не радовать, что наконец-то software engineering приближается к настоящей серьёзной инженерии. Пересмотр отношения к тестированию это один из шагов.

Следующим должен быть такой же пересмотр отношения к архитектуре, каждый инженер должен будет изучать различные архитектуры, недостатки, требуемые ресурсы, как настоящий архитектор.

Сейчас пока всё построено на трендовости, какой-нибудь новомодный RetardedDB появляется, и многие поддаются рекламе не удосужившись даже разобраться что там ничем новым и не пахнет, наоборот только хуже всё сделано.

А то сейчас слово engineering как-то незаслуженно там стоит. Хотя может это моё личное впечатление, я мало общаюсь с не инженерами.
(Ответить) (Thread)
[User Picture]From: gineer
2014-11-27 10:32 am
Все так...

только общего языка нет.
У инженеров это -- стандартизованые чертежи.

А у программистов наоброт -- ДСЛи, кто на какие горазд.

Так что архитектура... это еще не скоро.
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
[User Picture]From: stasorenburg
2014-11-27 07:09 am
LSB как-бы
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
[User Picture]From: ak_47
2014-11-26 11:35 pm
Думаю вы уже видели эту статью Коплина: Why Most Unit Testing is Waste. Он там не отрицает тестирование, но призывает более умному тестирванию, что-ли. При этом напирает на важность архитектуры. По моему личному опыту в большинстве компаний тесты имеют ценность либо близкую к нулевой, либо отрицательную.

Соглашусь с tr1gger насчёт архитектуры.
(Ответить) (Thread)
[User Picture]From: display_none
2014-11-27 12:25 am
Проблема в том что тестировать можно какой-то достаточно инкапсулированый компонент с внятным контрактом, не требующий построения вокруг себя огромного количества фиксчеров. Вот прямо такой, чтоб в требованиях было четко написано "на вход пришел X, вышел Y". Это может быть функция sum(), а может быть огромная система где на вход приходит поведение пользователя, а на выход -- GUI. Изначально, как и написано в статье, таким компонентом была функция. В современном же мире таким компонентом может быть целая подсистема или даже система целиком. Причем систему целиком все равно нужно тестировать (потому что работающие по отдельности части могут не срастись) и получается совершенно крамольная мысль о том что "юнит" вовсе не функция и не класс, а нечто большее и разделение на "функциональные" и "юнит" тесты более смысла не имеет.

Вот есть хрестоматийная система с GUI, BusinessLogic и DataBackend.

Можно отпилить GUI, и сказать что BL+DB=unit, и что контракт у него это use cases системы, и в таких вот терминах его и тестировать (причем если это ентерпрайз, то сценарии можно и вовсе на Gherkin писать).
И такие тесты будут полезны.
А если покрыть систему миллиардом тестов, каждый из которых проверяет один метод ORM или один метод класса из одной строчки, то в таких тестах можно потонуть а толку нуль. Они хрупки, и на них все равно все забивают и мьютят и они вообще не говорят о качестве системы:/

Самый треш это когда метод явно не имеет никакого контракта потому что он приватный и родился в рамках рефакторинга и вообще завтра умрет может быть. И вот к такому методу начинают писать тест. Причем написать тест нельзя не посмотрев реализацию метода (А это сразу говорит нам что мы влезли в середину абстракции, а не на ее границу, и что толка от такого теста не будет). Вот это потеря времени, да.

В общем догматизм это плохо, и для тестов тоже..
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: display_none
2014-11-26 11:46 pm
Господи, фря еще развивается?) Лет пять назад Интернет был заполнен печальными стонами фришников по поводу массовой миграции компаний на линух.

А с тестами как и с любой тулзой: через пару лет использования уже не понимаешь как можно что-то сделать без нее в принципе. Как можно быть уверенным что ты ничего не сломал, как можно спокойно комититься? Точно так же люди привыкают к CI, IDE, Scrum, языкам с лямбдами, async сахаром итд. Хочется думать что через какое-то время отсутствие тестов станет таким же нонсенсом, как и отсутствие VCS:)
(Ответить) (Thread)
[User Picture]From: dmarck
2014-11-26 11:54 pm
https://wiki.freebsd.org/WhatsNew/FreeBSD10
https://wiki.freebsd.org/WhatsNew/FreeBSD11

Ну и для информации: рабочий кластер FreBSD, за исключением совсем уж vital service machines, живёт на -current, и обновляется в норме раз в месяц. Eat your own dogfood

Total: Regular 121, Jails 112
Total current/stable installations: 233
Runnning -RELEASE|{-p*}: 3
Separate geographic sites: 6

Слава Peter Wemm.
(Ответить) (Parent) (Thread) (Развернуть)
From: ashamrin
2014-11-27 02:21 am

Dog fooding и сборка

Думаю, от отсутствия тестов спасает dogfooding. Разработчик BSD постоянно пользуется свежей версией ОС в процессе разработки. Недавно слушал интервью [1] разработчика Dragonfly BSD [2], в котором тот сказал интересуют мысль про сборку. По его словам, сборка ядра [3] на удивление полно испытывает операционную систему - файловую систему, виртуальную память, параллелизм (куча форков при выполнении горы шелл-скриптов, а также make -j), сеть (загрузка/закачка кода и результатов сборки) и т.д. и т.п.

В этом смысле понятно, откуда берутся традиционно слабые места Линукса/БСД. Например, поддержка 3д. Зачем 3д, что программировать? Для консоли/текстового редактора хватит простой 2д графики. Или suspend/resume - разработчику трудно оторваться от кодинга и компьютер никогда не спит. А когда спит программист, компьютер ночами собирает код :)

[1]: http://bsdtalk.blogspot.com/2014/11/bsdtalk248-dragonflybsd-with-matthew.html
[2]: Они используют git!
[3]: А еще лучше сборка всех пакетов в системе. В BSD это в порядке вещей, поскольку разрабатывают всё вместе, а не только ядро, как в Линуксе.
(Ответить) (Thread)
[User Picture]From: nec_p1us_u1tra
2014-11-27 10:53 pm

Re: Dog fooding и сборка

> Или suspend/resume - разработчику трудно оторваться от кодинга и компьютер никогда не спит. А когда спит программист, компьютер ночами собирает код :)

Основная цель суспенда -- в живой миграции, а не в ноутбуке. Всякие Блумберги хотят виртуальных машин, тысячи их, причем сторажд отделена от вычислительных мощностей, и виртуальная машина мигрируется туда-сюда в зависимости от потребностей.
(Ответить) (Parent) (Thread)
[User Picture]From: alex_vinokur
2014-11-27 04:26 am
Слегка офф-топик.
Крайне рекомендуется:
Майерс "Искусство тестирования программ"
(Ответить) (Thread)
[User Picture]From: alexis_m
2014-11-27 04:39 am
Еще чуть офф-топик. А почему не на виртуальную машину?
(Ответить) (Thread)
[User Picture]From: avva
2014-11-27 06:45 am
Нет особой причины. Ну, я пару лет не пользовался виртуальными машинами дома (а на работе все свое, не стандартное), поэтому надо было бы разобраться, что установить, найти уже готовую болванку-image FreeBSD, итд. Я вспомнил, что у меня есть оплаченный дешевый dedicated server в сети, которым я не пользуюсь, зашел в его менеджер и сказать переустановить ОС на FreeBSD - это оказалось легче. Если б его не было, сделал бы виртуальную машину.
(Ответить) (Parent) (Thread) (Развернуть)
(Удалённый комментарий)
[User Picture]From: romikchef
2014-11-27 08:30 am
Разумеется, нет.
"выполнить задачу по получению исходников" - это всё, для чего нужна VCS?
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
(Удалённый комментарий)
From: migmit
2014-11-27 09:28 am
На C/C++ - да. На Erlang - да.

На Perl - нет, поскольку на нём писать вообще нельзя.

На Haskell - нет, ибо система типов. Как раз на нетривиальных кусках кода она выручает очень сильно.
(Ответить) (Thread)
[User Picture]From: link0ff
2014-11-27 11:01 am
На Perl писать можно, только читать нельзя :)
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: link0ff
2014-11-27 11:06 am
На опыте я убедился, что тесты нужны только для библиотек, используемыми другими программистами. Для сложных web-приложений тесты писать нерационально, для них главное иметь всеобъемлющий error-processing и детальный error-reporting.
(Ответить) (Thread)
[User Picture]From: _iga
2014-11-27 04:58 pm
А как Вы представляете, например, тесты для сетевого драйвера?
(Ответить) (Thread)
From: triampurum
2014-11-27 05:52 pm
Нам-то хочется, чтоб все правильно работало, а тесты дело второе. Тесты - это по бедности, верифицируем чем можем. А так-то представляется, например, так, или, скорее, так.
(Ответить) (Parent) (Thread)
[User Picture]From: cryinstone
2014-11-27 09:56 pm
Тесты сильно зависят от того, кто их пишет и правит - какие сценарии учтены, какие нет. Само наличие тестов - это не silver bullet.
Но да - тесты есть очень положительная штука, без них тяжело, особенно делать модификации и рефакторинги без того, чтобы где-то в самом неожиданном месте что-то не сломалось.
(Ответить) (Thread)