Как юнит-тестить распределенные проприетарные системы?

А почему нельзя применять TDD, отталкиваясь от ТЗ?

Допустим, заказчик прислал Vision и/или ТЗ. Были написаны тесты, написан код к ним. И, т.к. мы считаем за истину, что код соответствует ТЗ и спеке протокола, значит проблема не нашей стороне, читай «не наша зона ответственности».

Если код написан по всем правилам спеки не работает, значит реализация протокола некорректна. Но вы же не протокол разрабатываете.

Написать мок thirdparty-сервиса в соответствии со спецификацией и гонять тесты на нем в качестве бекенда.

Там нетривиальный стэк протоколов, с нашей (клиентской) стороны над ним работает не один чел, включая аутсорс, нам даются уже готовые клиентские либы, а мы пишем с этими либами конкретный апп. Проблема в том, что иногда баги и в нашем (не нашей команды, но нашей конторы), платформенном коде для клиентов.

Т.е. при грамотном распределении труда, такие тестовые моки сервиса должны писаться один раз для всей платформы и клиентов, но не для каждого аппа разными людьми выдумываться свои мок-велосипеды. Благо, структура сообщений уровня приложения одинакова, различается только контент. Т.е. можно разработать тестовое клиент/серверное приложение X, которое будет и тестом, и примером реализации для разработчиков конкретных аппов.

По крайней мере, таким образом можно тестить все уровни кроме уровня приложения (всевозможные сценарии разрывов сессий, ошибок и т.п.). Так ведь?

Т.е. ни о каком test-driven-development при таком подходе к разработке не может идти речи

при чем тут TDD вообще и юнит-тесты в частности? то, что ты описываешь - интеграционные тесты, которыми обычно занимается как раз «специальный чел». на своей же стороне - обмажтесь моками по спецификации сервера и тестируйте как хотите.

можно разработать тестовое клиент/серверное приложение X, которое будет и тестом, и примером реализации для разработчиков конкретных аппов.

у вас бюджет неосвоенным пропадает? нахрена вам это надо, если каждой конкретной команде скорее всего нужна пара-тройка методов, которые на месте реализуются за 15 минут?

Очевидно, что надо смокать транспорт и записывать/проигрывать дампы данных.

Можно смокать ещё и сервер.

единственное что - если там ну уж очень все нестандартно - ну наваяйте свой фреймворк, на базе которого моки можно будет писать быстрее

Описанное тобой - интеграционное тестирование.

Если код написан по всем правилам спеки не работает, значит реализация протокола некорректна.

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

вотерфольщики в чяте, все в машину.

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

вотерфольщики в чяте, все в машину.

Тебе важнее умными словами покидаться и понты покидать или все же работу сделать? Лично мне насрать, как называется способ разработки, главное чтобы эффективно решал задачи, а то что он кому-то кажется недостаточно agile или не тем местом driven - это личные трудности фанатиков.

неполная спека - не повод...

И где, по твоему я предлагал отказаться он модульного или интеграционного тестирования? У тебя фантазия слишком бурная и общаешься ты со своими галлюцинациями.

никак не тестить.

юнит тесты должны быть ограниченными юнитом и детерминистичными, а распределённые системы можно тестировать только как системы и, часто, вероятностно.

да и не всё в принципе покрывается юнит тестами. а то что там рабиновичи пусть и дальше поют про свои tdd и прочую ересь.

такие тестовые моки сервиса должны писаться один раз для всей платформы и клиентов, но не для каждого аппа разными людьми выдумываться свои мок-велосипеды. Благо, структура сообщений уровня приложения одинакова, различается только контент. Т.е. можно разработать тестовое клиент/серверное приложение X, которое будет и тестом, и примером реализации для разработчиков конкретных аппов.

Похоже, вам нужен имитатор сервера - скооперируйтесь и напишите. Но это, как уже отметили, интеграционное тестирование, а не TDD.

Так же как все остальные. Юнит-тесты не имеют отношения к: чтению с диска, базам данных и в том числе к сетевым соединениям, которые в общем суть распределенных систем. Для этого есть другие — функциональные и интеграционные тесты.

Т.е. ни о каком test-driven-development при таком подходе к разработке не может идти речи. Или?

TDD используется для пруфинга что код модуля соответствует спекам в их текущем виде — в случае добавления фич — что отсутствуют регрессии. В случае багфикса, что баг не воспроизводится (если он вообще зависит от условий, которые можно проверить на уровне юнит-теста, что не всегда так). В идеале это встроено в цепочку CI и если тест не проходит — падает билд :) Кроме TDD есть еще BDD - поведенческо-ориентированная разработка, которая в общем и целом может быть надстройкой над собранными на раньших этапах модулями и целыми кусками системы. На практике поддержка этого дела занимает время (особенно если девопсы «где-то там», выделенный билд-инженер отстутствует как класс и CI в лучшем случае мутится по шаблонам в облаке, которые всегда «морально устаревшие», в худшем — на коленке), на что ради ложнопонятого ублажения клиентов руковоцтво проэктов «проявляет гибкость» и часто забивает вообще — т.е. делают мину «крутитесь как хотите, если это вам помогает — делайте, но мы клиентам важность и нужность объястнять не будем, не маленькие — сами разберетесь», соответственно время на развертывание и сопровождение CI нигде не учтено, юнит-тесты близко к дедлайну становятся формальностью и «нинужной фигней, на которую вы тратите время». Соответственно саппорт потом расхлебывает дополнительный геморрой с тестами, которые в принципе не отражают и не соответствуют (часто полны срезания углов и мухлежа, чтоб обойти CI-фильтры :)) Аджайло-буззворды про «непрерывное деливери» и «побыстрее отдать в продукшон» тут часто приплетают как в анекдоте про пулемет, патроны которых нет и политрука «Ну ты же комсомолец! И пулемет застрочил вновь». Т.е. ситуация: рыбы нет, но вы жарьте — это совершенно нормальное явление с рогами :)

Но опять таки, если это касается проверки работы клиента-сервера в связке, это не относится к юнит-тестам. Юнит-тесты — это про мокапы, входные и выходные данные, которые «вот такие по спекам модуля и ниибет, а если не такие — то это фейл где-то еще».

вотерфольщики

Как что-то плохое. Расскажи тут про «большие проекты»(ТМ), сделанные по аджайлу :)

не расскажу, пушшо NDA, но они есть.

при чем тут TDD вообще и юнит-тесты в частности? то, что ты описываешь - интеграционные тесты, которыми обычно занимается как раз «специальный чел». на своей же стороне - обмажтесь моками по спецификации сервера и тестируйте как хотите.

++

Юниттесты тестируют код. Формат системы роли не играет.

высказался и полегчало? ну малаца, только если хочешь, чтобы тебя слушали - начни с азов, как минимум с понимания разницы между видами и уровнями тестирования. и не лепи тут чушь про «функциональные и интеграционные тесты»

тестами, которые в принципе не отражают и не соответствуют (часто полны срезания углов и мухлежа, чтоб обойти CI-фильтры)

или другими словами «мы говношлепы, ни тесты ни код писать не умеем, но во всех проблемах виновата agile методология вообще и CI/CD в частности»

TDD используется для пруфинга что код модуля соответствует спекам в их текущем виде — в случае добавления фич — что отсутствуют регрессии.

омфг, какую же хрень ты несешь. TDD используется только для разработки и к тестированию отношения не имеет. никакого пруфинга на основе TDD не делается и делать не можется, а тебе, перед тем, как вещать о том, что что-то не работает, не помешало бы хотя бы азы используемой методологии освоить, вместо того чтобы путать TDD и test first, например

или простыми словами - скройся, ты тупой и не в теме

Юниттесты тестируют код. Формат системы роли не играет.

Люди тестируют код. Формат системы роли не играет.

а на деле юнит тесты хороши для алгоритмического кода и очень так себе для тестирования вещей связанных через API с системой (где система - это os, железо, сети, базы данных и пр.).

напишешь драйвер файловой системы по TDD?

Юнит-тесты не имеют отношения к: чтению с диска, базам данных и в том числе к сетевым соединениям, которые в общем суть распределенных систем. Для этого есть другие — функциональные и интеграционные тесты.

Юнит-тесты и интеграционные тесты - разновидности функциональных тестов.

а на деле юнит тесты хороши для алгоритмического кода и очень так себе для тестирования вещей связанных через API с системой (где система - это os, железо, сети, базы данных и пр.).

О чем и речь. Идеалогия юниттестов — это тестирование кода, не интерфейса, не юзабилити, не надежности всей системы, не качество решения задачи, а только тестирование кусочков кода.

Нужно тестировать другое — используйте другие методики тестирования.

Это не юнит-тесты.

напишешь. TDD этому никак не помешает. тестировать его придётся интеграционно, но это другой вопрос.

поймите уже блин, TDD - это не про тестирование. тесты в TDD - это способ документирования кода и формализации требований

соответственно время на развертывание и сопровождение CI нигде не учтено, юнит-тесты близко к дедлайну становятся формальностью и «нинужной фигней, на которую вы тратите время». Соответственно саппорт потом расхлебывает дополнительный геморрой с тестами, которые в принципе не отражают и не соответствуют (часто полны срезания углов и мухлежа, чтоб обойти CI-фильтры :))

мы такой радости уже словили по глотку, причём мне с самого начала было ясно, что если на систематическое тестирование (и юнит-тесты, и функциональное и интеграционное) забить через пару месяцев после начала проекта, потому что «подумать нужно было уже вчера, новых разрабов набрали сегодня, а завтра как-нибудь прорвемся, вы только поработайте в выходные разок-другой», то начиная с середины проекта есть только один единственный вариант аллокации временных ресурсов разрабов - писать код без оглядки на тесты сразу и без багов, и тут же его тестировать на цельной системе. К концу проекта менеджмент начинает осознавать сложность проекта, и в спешном порядке добирает до кучи ещё и тестеров, в т.ч. со стороны заказчика. Но все сроки уже давно сорваны.

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

ну то есть проблема не в сервере, не в протоколе и не в методологии. проблема в том, что у вас все через одно место. непонятно только, почему совета ты просишь на лоре и не о том, о чем надо

тесты в TDD - это способ документирования кода

смешно. но есть те, кто в это свято верует.

==========

ну и не напишешь ты. сначала напишешь фейковую подсистему I/O ядра, а потом напишешь инфраструктуру запуска тестов. а вот потом, может быть, через полгода, приступишь к драйверу.

ну или плюнешь на всё и вставишь тестовый диск, чтобы его мучить тестами. но это всё затянется на месяцы.

ну, человеку, который понятия не имеет о том, как нужно использовать инструмент, который ему дали - конечно же виднее, что и как сделает с этим инструментом тот, кто им пользуется правильно

да-да. научи меня автотестировать.

а про «тесты в TDD - это способ документирования кода и формализации требований» - это как в Planescape: Torment чел был, который ребусами разговаривал. Так и тут «документация» того же рода.

и да - дай ссылку на свои проекты, которые ты писал по TDD.

куда тебя учить автотестировать, тебе нужно с чтения начинать. автотестировать оно рвется, через TDD что-то доказывать собирается. скройся с глаз моих, ничтожество безграмотное

и да - вот тебе мой, который писался строго на автотестах. при этом TDD был послан в жопу. https://github.com/dzidzitop/ant_modular

а ты - балабол.

ну и не напишешь ты. сначала напишешь фейковую подсистему I/O ядра, а потом напишешь инфраструктуру запуска тестов. а вот потом, может быть, через полгода, приступишь к драйверу.

Извините, я в ынтерпрайзе мало понимаю, но какая «инфраструктура запуска тестов» вам нужна?

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

Диск-то зачем? На файле будешь тренироваться. ФС - это не то, что обязано писаться на реальном железе.

можно и на файле.

инфраструктура для запуска тестов модуля ядра без самого ядра. тема называется «юнит», напомню.

если запускать интеграционные тесты, то, вероятно, особо отчаянные авторы могут и на живом ядре в виртуалке их гонять. дебажить особо не получится, правда.

инфраструктура для запуска тестов модуля ядра без самого ядра. тема называется «юнит», напомню.

Так вот, сложная ФС - это просто куча сложного кода. Который можно вынести в библиотеку и тестировать совершенно обычными средствами. Конечно, код взаимодействия с ОС так проверить не получится, но это будет уже интеграционный тест.

если запускать интеграционные тесты, то, вероятно, особо отчаянные авторы могут и на живом ядре в виртуалке их гонять

Для всего, кроме драйверов железа, запуск в UML/qemu/KVM - обычная практика. О каком отчаянии ты говоришь - я просто не понимаю.

дебажить особо не получится, правда.

Всё получится.

который писался строго на автотестах. при этом TDD был послан

и что мне это должно доказать кроме того, что ты понятия не имеешь о TDD и его роли в разработке?

если сделать прослойку между системными вызовами I/O, то может и получится тестировать и дебажить обычными средствами, собирая с тестовой версией прослойки. А так - тот сложный код без I/O неработоспособен.

Я об авторах, которые не боятся трудностей.

В общем согласен - получится покрывать тестами это. Осталось понять каким образом в этом поможет TDD.

вы идиоты оба два. «время на развёртывание и сопровождение CI» - это 15 (прописью: пятнадцать) минут при установленном дженкинсе и 1 (один) час если дженкинса ещё нет. если у вас это занимает времени столько, что это влияет на сроки релиза - это не CI виноват, а то, что вы кривожопорукие калечи

балабол, код свой тддшный покажи.

А о TDD ты мне ничего нового не скажешь.

Осталось понять каким образом в этом поможет TDD.

Даже в этом топике, разные люди понимают под TDD разные вещи.

TDD - это

1) write a test first that must fail

2) fix the test (in a simple way) until all tests are «green»

3) refactor if needed

4) goto 1

ничего другого за этим понятием стоять не может. может быть только разное ожидание что это даст и как придумать достаточное количество тестов, чтобы покрыть ими требования.

2) fix the test (in a simple way) until all tests are «green»

fix the test

уйди. просто уйди

балабол, почитай в оригинале

https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530

и прекращай нести чушь и показывать немытую пипиську вместо кода.

ты сам-то осиль оригинал, недоумок, перед тем, как на людях своим петпрожектом трясти, в котором ты обошелся без TDD не понимая, что это такое (охрененное достижение, конечно)

по делу есть что сказать?

вот тебе тдд в картинках, если текст книги не понял:

http://cdn.ttgtmedia.com/rms/onlineImages/software_quality-test_driven_testin...

и да, вытаскивание «fix the test» в отрыве от контекста, где подразумевается fix the code, лишний раз доказывает, что ты идиот, который не умеет ни читать, ни тестировать но имеет по этому поводу свое охрененное мнение. уходи

ну т.е. сказать по делу нечего. как обычно.

в общем, dzidzitop безнадежен, для остальных присутствующих объясняю разницу между test first и TDD на пальцах:

test first - до начала разработки модуль покрывается полным набором тестов и потом код пишется до тех пор, пока все они не позеленеют. написанные тесты потом используются как часть общего сьюта и дают представление о том, правильно работает код или нет

TDD - до начала разработки на модуль пишется один тест, покрывающий ровно один позитивный сценарий. код пишется пока этот тест не позеленеет, тест после этого ни в какой сьют не попадает, вместо этого отдельно пишутся тесты (в том числе на его основе) которые реально тестируют, а не служат индикатором выполненной работы, в отличие от теста, написанного в рамках TDD. тест в TDD можно заменить блокнотом с пунктами или ещё чем-то, тестом в терминах QA он не является.

dixi

ну и чтобы закрыть тему (которая и так уже ушла далеко) - пара слов о BDD. несмотря на то, что звучит это очень похоже на TDD, на самом деле BDD гораздо ближе к test first. в схеме BDD заказчик или продукт овнер на каком-либо DSL пишет тот же самый тест, как и в TDD, но на человекопонятном языке. проблема в том, в 99% случаев DSL довольно жирный и в итоге тест покрывает гораздо больше сценариев, чем TDDшный тест, хоть и служит, как и в TDD индикатором выполненной работы. при желании бддшные тесты даже можно собирать в сьют и использовать на CI, но лучше так не делать - по своей природе и из-за особенностей DSL он скорее всего будет падать в непредназначенных для этого местах, и все это написанное заказчиком говно лучше переписать в набор атомарных тестов, которые будет гораздо проще саппортить.

теперь точно всё