Статья красивая, и нет ответа на главный вопрос их заголовка: «Можно ли «сломать» интернет?» Вы рассмотрели ряд вариантов, а потом показали, что они трудновыполнимы (ну кроме ЯО, разве что). Однако Вы нигде не рассмотрели вопрос: а есть ли еще способы нарушения работы сети?
Возможно есть простой и эффективный способ, а Вы его просто не рассмотрели.
То есть, по сути, заголовок логичнее поменять на «Ряд способов нарушения работы интернета».
Нет-нет, возможно, я неправильно написал. Основная идея: для тестирования .Net проекта требуется установленная Java.
Есть FitNesse — система, чтобы запускать тесты. Там поддерживаются плагины на любом языке программирования (см. тут). У меня просто еще один плагин, не более того.
И это всё не так важно, я пробовал описать не свои какие-то проекты, а Tool, который помогает мне в разработке.
Нуждается в доказательстве. Как Вы проверили, что в интернете отсутствуют другие видео? Или Вы смотрели только официальные видео?
дважды просмотрел код рефлектором
Вы просмотрели весь код новой технологии? Если не секрет: сколько времени у Вас было потрачено на анализ кода, анализ того, почему используется эти подходы, а не иные и пр.
Если все изучение начинается и заканчивается маркетинговыми материалами
В начале статьи приведены ссылки на книгу, сайт MS и статью на хабре. Причем последнее вряд ли является маркетинговым материалом.
Но я как-то привык читать код и анализировать готовые решения ДО того, как кидаться применять технологию.
А по какой метрике Вы определяете, что Ваши знания о технологии дошли до необходимого уровня? Если Вы будете читать вообще весь код всех используемых библиотек, то у Вас уйдет около 5-10% времени, которое потратили разработчики (пруф). Ну то есть если Вы захотите выбирать между пятью технологиями, то Вам можно просто её сделать с нуля за сопоставимое время
При этом МС таки использует технологию и эти баги не сильно беспокоят.
Мы обращались в Support Microsoft по поводу этой технологии. Ответ был, примерно, таким: «Да, эта технология забагована, так что, скорее всего, вы нарвались на один из багов ...»
Кстати, а можно Вас попросить аргументировать фразу «что автор использует неверный подход»? Задача такая: у нас есть около 1000 Workflow Instance и, допустим, 5 запущенных процессов. Ожидания: все процессы распределят нагрузку равномерно. Если запустить только один процесс, то время обработки займет час. Вопрос: как правильно использовать технологию MS Workflow таким образом, чтобы время обработки сократилось раз в пять, примерно (ну то есть чтобы не первый процесс забрал все задачи, а они бы распределились равномерно). Каждый процесс запущен на отдельном сервере.
Я вижу недостаток, что автор использует неверный подход, при этом ругает технологию. К сожалению МС не озаботились дать верный подход, его приходится выковыривать из продуктов.
Не соглашусь. Если в продукте баг (такое бывает), и я на него наткнулся, хотя не отступал от методичек автора технологии. Такое возможно, и в этом случае нельзя сказать, что был неверный подход. Это просто бага в технологии, не более того.
А вариант «написать самому» вообще не рассматривается что ли? :)
Тут есть тонкий момент. Проект живет на Production около шести лет. Первый релиз делал не я, но, как мне стало понятно, алгоритм принятия решения был, примерно, таким: «О, я услышал на конференции про крутую тему — Workflow. На ней можно кастомизировать наши бизнес-процессы. Давай попробуем, как оно. Только быстро». Разработчик ответил — не вопрос. Он реализовал быстренько методы, быстренько доделал дизайнер и готово. И это было реально шустро. Более того, оно проработало несколько лет, причем Engine почти не претерпевал изменений.
Сейчас, если бы у меня стояла задача сделать то же самое, я бы не раздумывая сделал своё. Для меня это было бы и быстрее по срокам, и надежнее в плане работы. А вот если взять программистов, которые ни разу не делали ничего подобного (Enterprise проект, Вы понимаете, что там операции только web-база-web, никакого дикого параллелизма, всё просто, кроме маленьких соседних модулей, и это скорее исключение), то им лучше дать хоть что-то готовое. Тогда бы проект вышел бы в свет в более-менее разумный срок. Как MS сталкивалась с ошибками при разработке, так и пришлось бы этим разработчикам столкнуться.
Так что тут всё зависит от того, насколько команда имеет опыт разработки параллельных/распределенных задач. Если опыт есть — пусть пишут сами. Если опыта нет, но утвержденные (!) планы грандиозны — тогда пусть пишут сами. Если особых планов нет, просто хотелось бы побыстрее сделать маленький кусок, а далее, если пойдет, то еще доделать, то тут лучше взять готовое. Это, естественно, моё мнение.
Я Вас не понял… Изначально Activity — это то, что будет нарисовано в дизайнере + то, что будет выполняться + то, что будет сохраняться.
На тему сложной штуки — абсолютно нет, он скорее запутанный.
Я предлагал сохранять для каждой Activity не всё, а только State. Это не отменяет того, что, скорее всего, потребуется еще хранить сам алгоритм работы, параметры по умолчанию и т. д.
Тут всё зависит от того, насколько система должна быть стабильной, и насколько много через неё проходит задач. UnloadOnIdle всегда выставляется в true, иначе наши Activity всегда будут в памяти, если не вызывать периодически метод Unload.
То есть, если UnloadOnIdle == true, то будут вот такие особенности:
1. В памяти больше Activity, а это падение производительности (см. график в статье) для остальных + заблокировано большее количество Workflow Instance, чем следует. Кстати, это тоже падение производительности. И не забываем про блокировку, ограниченную во времени, то есть мы не может совсем долго тянуть с Unload.
2. Нам потребуется вызывать метод Unload самостоятельно. На деле это очень и очень плохая идея, так как сделан он крайне криво. Дело в том, что если Workflow Instance не находится в памяти, то он сначала будет Load, а потом — Unload. Двойной Load для Instance приводит к порче памяти, а такое возможно, если загрузка идет в нескольких потоках (еще одна проблема Microsoft Workflow, кстати). Более того, если Workflow Instance удален (то есть как-то остановился, не важно даже как), в памяти его нет, а мы сделали Unload, то сначала произойдет Load, а, раз Workflow Instance отсутствует в памяти и в базе, мы получаем исключение на ровном месте. А дальше, с малой долей вероятности (я не смог отследить правильную последовательность действий), мы еще и получим ломаный Workflow Instance в памяти, который не может быть выгружен, и из-за которого не будет останавливаться Workflow Runtime.
Всё это мы, конечно, не сразу получали, а постепенно, экспериментальным путем. В общем, я бы не советовал вручную рулить загрузкой и выгрузкой.
Я Вас не понял. Delay Activity — это пауза на N секунд. Просто пауза, если мы говорим про загрузку, то тут должны быть какие-нибудь Save/Load Activity (их нет, кстати). У нас пауза была для каждого WCF соединения, чтобы вызвать его еще раз, если прошлый вызов не заработал. А если он сработал — то не ждем. Вот в таком алгоритме, по моему мнению, нулевое ожидание следует понимать как команду NOP.
Здесь есть варианты, однако есть два основных:
1. Используйте класс Workflow Runtime, чтобы сообщать об Event'ах, запускать процессы и останавливать их
2. Можно хостить Workflow как web-сервис (более того, можно это делать на разных серверах). Тогда общение будет происходить через WCF
В целом, схема такая:
1. Запускаете рабочий процесс. Он работает, вызывает сервисы, посылает письма, ждет — в общем, что-то делает.
2. Если Вам требуется, иногда, ждать действий пользователя, то поддерживаете Event Model. Ну то есть идете дальше, если приходит этот самый Event.
Например, если у Вас web приложение, то event можно посылать в момент обработки пользовательского запроса. Дальше Workflow крутанется и как-нибудь отреагирует. Например, если требуется проверять, что пользователь правильно заполнил форму, можно использовать Workflow: оно сначала проверит, что всё более-менее правильно, потом отправит письма и т.д. Программист создает только отдельные кубики, аналитик их соединяет и настраивает.
Да, такое у нас тоже работало. У нас вот что было: некоторые Activity запускались раз в сутки (проверили и спят дальше). И, соответственно, всего около 20 000 — 40 000 рабочих процессов. И около 5 000 — 8 000 имели ежедневную активность, но были размазаны более-менее по суткам. И всё было хорошо до тех пор, пока платформу не остановили на выходных на сутки где-то. Дальше ежедневные ребята резко начали работать. Результат я описал.
Возможно, Вам лучше посмотреть еще этот пост, в нем есть картинки по созданию.
Для аналитика:
В случае прототипа можно остановиться на Visual Studio Express, в котором можно создать дизайн. Для реальной платформы корректнее всего потом создать свой дизайнер, чтобы избежать разного рода code-injection (так как if activity содержит, например, код для выполнения). Плюс стандартный дизайнер далеко не самый удобный. Самое главное — чтобы в конце получался строчка с xaml с бизнес-процессом.
Для пользователя:
По идее, он вообще не должен особо видеть, что работает внутри. Он должен четко знать, что на его действие А система реагирует действием Б. И всё. А уже как оно происходит не особо важно. Разве что заказчик должен знать, что процесс всегда можно поменять лично для него.
Однако я не нашёл способа, как, например, избавиться от проблемы некорректной загрузки (то есть загрузки по 1000 элементов за раз). У вас была такая задача?
Вы правы, стандартный дизайнер сложен для понимания. Он, кстати, используется в TFS, чтобы создавать сценарий билда. Я пока только один раз услышал хвалебный отзыв о этой фиче. Так что тут я с Вами полностью согласен.
Workflow 3.0 можно было использовать для создания дизайна все MS VS. Причем даже не линкуясь на сборки MS VS. Я могу код быстренько сделать и продемонстрировать, если это требуется. Более того, если разрешить кидать на холст (для рисования) только свои Activity + справа сделать вывод свойств, то получится в более-менее нормальный дизайнер. Так что Вы не правы.
WF 3.0 идет как отдельная библиотека в .Net 3.0: %systemdrive%:\Windows\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation. То, что он появился изначально в другой технологии, не так важно начиная уже с .Net 3.0, так как библиотеки Workflow не линкуются.
Про SharePoint 2013 — я не про него писал, а про то, какие интересные моменты от использования Workflow в своих приложения. Так-то да, нам следует взять объект Workflow Runtime и все запуски делать через него.
На тему параллельной работы: блокировка объектов происходит функцией RecoverInstanceLocks (я вставил выдержку из кода ниже). Это код WF 4. В предыдущей версии стиль тот же, просто нет top 1000. Как Вы понимаете, всё хорошо только в случае, если у нас все задачи очень быстрые. Более того, через две минуты придет новая порция данных, даже если эти еще не обработанные. Что в паре с нелинейной асимптотикой производительности дает плохой результат.
RecoverInstanceLocks
insert into [RunnableInstancesTable] ([SurrogateInstanceId], [WorkflowHostType], [ServiceDeploymentId], [RunnableTime], [SurrogateIdentityId])
select top (1000) instances.[SurrogateInstanceId], instances.[WorkflowHostType], instances.[ServiceDeploymentId], @now, instances.[SurrogateIdentityId]
from [LockOwnersTable] lockOwners with (readpast) inner loop join
[InstancesTable] instances with (readpast)
on instances.[SurrogateLockOwnerId] = lockOwners.[SurrogateLockOwnerId]
where
lockOwners.[LockExpiration] <= @now and
instances.[IsInitialized] = 1 and
instances.[IsSuspended] = 0
Сразу отмечу, что пост я писал не для того, чтобы показать, как всё плохо. Нет. Он создан для того, чтобы разработчики уже более-менее знали, как бороться с этими особенностями. Раз я видел ошибки в проекте, то логично, что есть (и будут) другие проекты, где они тоже появятся. Как Вы видите, у меня на каждую недоработку есть решение.
Тут, наверное, резоннее мне было бы показать, как можно сделать. Я бы разделил каждую Activity на три части: View, State, Execution. View показывается в дизайнере, её задача: создать State по умолчанию. State — это текущее состояние Activity (то есть кубика), он и только он сохраняется в базу. Execution — это Singleton уровня Instance или приложения — не знаю, как бы я делал, но самое главное, что он бы не сохранялся в базу. И его схема работы была бы следующей: на вход State, на выходе State + еще опции (что-то вроде «эта activity завершилась» и т. д.). Как Вам такая реализация? Здесь сложнее сделать ошибку с сохранением.
Про сохранение — я привел в пример delay activity, когда ждать следует 0 секунд. Зачем здесь сохраняться?
Нет, мы работали напрямую. FitNesse хранит все файлы в виде txt. Ну и мы, соответственно, подменяли txt файлы скриптом. Напрямую. Ну и такой фокус не всегда срабатывал.
Про функцию зеркалирования не знал, огромное спасибо. Изучу.
Я посмотрел по диагонали на SpecFlow, если я буду ошибаться — исправьте, пожалуйста. Для .Net разработчика, по моему мнению, преимуществ нет. Так как разработчику проще всего писать тесты в MSTest или в чем-то подобном. Ну так как все знают языки программирования, все умеют программировать, у всех куплена Visual Studio.
С билдами его легко интегрировать: см. соседние комментарии. На создание тестов будет потрачено значительно больше времени, чем на подобную интеграцию.
Преимущество FitNesse в ином: Вы можете разделить разработку самих тестов и создание API. На деле это действительно получается (у нас получалось), ведь тестировщик может использовать еще несуществующие функции при создании тестов (запустить он их не сможет). Допустим, нам нужна функция переименования пользователя. Тестировщик напишет (верстка едет, табличка не получилась..):
Тест не запустится — функции-то нет. И создается баг в трекере: требуется функция…. У нас получалось создавать тесты параллельно с API, что довольно круто.
Продолжая сравнение: SpecFlow , как я понял, требует установленной Visual Studio для разработки, тестирования и запуска, верно? А это еще + $1 000 за каждую платформу. Это не большие деньги для компании, но сам факт наличия дополнительных трат может стать серьезной преградой.
Однако если исключить меркантильность и то, что студия кушает больше ресурсов, чем браузер, то получаем, что серьезных преимуществ у FitNesse нет (разве что комьюнити, что не всегда уж и надо). На тему удобства мне сложно что-то говорить, так как я не работал со SpecFlow. Скорее всего, у них есть подсветка кода, выполнение на билд сервере, а не локально (не настраивать же тестировщикам платформы локально?) и всё то, что требуется.
Добавлю еще опыт. Дело в том, что в FitNesse есть небольшая особенность: он может потерять тест, если его обновить на файловой системе напрямую (то есть просто поменять файл). Такое не всегда действует, однако мы это стабильно получали из-за того, что тесты хранятся в Source Control. Таким образом, тесты копировались в «главный» FitNesse и запускались из него же (на билд сервере несколько бранчей, хотелось иметь один Web Ui). Ну и при копировании иногда FitNesse терял тесты до следующего запуска, что совсем не круто.
Решается данная недоработка просто: FitNesse можно запустить в режиме «выполнить всё и завершиться». Ну то есть Rest он выполнит сам у себя. Я привел в статье пример, но, чтобы не искать: java.exe -jar «fitnesse-standalone.jar» -d D:\ -c «MyTests?suite&format=xml» -b «d:\builds\TestsResults.xml»
Аргументы:
1. Путь к Jar файлу.
2. -d + путь к папке, в которой лежит fitNesseRoot
3. Наша Rest комманда
4. -b + путь к результирующему xml файлу.
После этого наш CCNet преобразует xml в красивый html для письма (с подсветкой упавшего и пр.).
Возможно есть простой и эффективный способ, а Вы его просто не рассмотрели.
То есть, по сути, заголовок логичнее поменять на «Ряд способов нарушения работы интернета».
Есть FitNesse — система, чтобы запускать тесты. Там поддерживаются плагины на любом языке программирования (см. тут). У меня просто еще один плагин, не более того.
И это всё не так важно, я пробовал описать не свои какие-то проекты, а Tool, который помогает мне в разработке.
Нуждается в доказательстве. Как Вы проверили, что в интернете отсутствуют другие видео? Или Вы смотрели только официальные видео?
Вы просмотрели весь код новой технологии? Если не секрет: сколько времени у Вас было потрачено на анализ кода, анализ того, почему используется эти подходы, а не иные и пр.
В начале статьи приведены ссылки на книгу, сайт MS и статью на хабре. Причем последнее вряд ли является маркетинговым материалом.
А по какой метрике Вы определяете, что Ваши знания о технологии дошли до необходимого уровня? Если Вы будете читать вообще весь код всех используемых библиотек, то у Вас уйдет около 5-10% времени, которое потратили разработчики (пруф). Ну то есть если Вы захотите выбирать между пятью технологиями, то Вам можно просто её сделать с нуля за сопоставимое время
В общем, хотелось бы аргументации.
Мы обращались в Support Microsoft по поводу этой технологии. Ответ был, примерно, таким: «Да, эта технология забагована, так что, скорее всего, вы нарвались на один из багов ...»
Кстати, а можно Вас попросить аргументировать фразу «что автор использует неверный подход»? Задача такая: у нас есть около 1000 Workflow Instance и, допустим, 5 запущенных процессов. Ожидания: все процессы распределят нагрузку равномерно. Если запустить только один процесс, то время обработки займет час. Вопрос: как правильно использовать технологию MS Workflow таким образом, чтобы время обработки сократилось раз в пять, примерно (ну то есть чтобы не первый процесс забрал все задачи, а они бы распределились равномерно). Каждый процесс запущен на отдельном сервере.
Не соглашусь. Если в продукте баг (такое бывает), и я на него наткнулся, хотя не отступал от методичек автора технологии. Такое возможно, и в этом случае нельзя сказать, что был неверный подход. Это просто бага в технологии, не более того.
Тут есть тонкий момент. Проект живет на Production около шести лет. Первый релиз делал не я, но, как мне стало понятно, алгоритм принятия решения был, примерно, таким: «О, я услышал на конференции про крутую тему — Workflow. На ней можно кастомизировать наши бизнес-процессы. Давай попробуем, как оно. Только быстро». Разработчик ответил — не вопрос. Он реализовал быстренько методы, быстренько доделал дизайнер и готово. И это было реально шустро. Более того, оно проработало несколько лет, причем Engine почти не претерпевал изменений.
Сейчас, если бы у меня стояла задача сделать то же самое, я бы не раздумывая сделал своё. Для меня это было бы и быстрее по срокам, и надежнее в плане работы. А вот если взять программистов, которые ни разу не делали ничего подобного (Enterprise проект, Вы понимаете, что там операции только web-база-web, никакого дикого параллелизма, всё просто, кроме маленьких соседних модулей, и это скорее исключение), то им лучше дать хоть что-то готовое. Тогда бы проект вышел бы в свет в более-менее разумный срок. Как MS сталкивалась с ошибками при разработке, так и пришлось бы этим разработчикам столкнуться.
Так что тут всё зависит от того, насколько команда имеет опыт разработки параллельных/распределенных задач. Если опыт есть — пусть пишут сами. Если опыта нет, но утвержденные (!) планы грандиозны — тогда пусть пишут сами. Если особых планов нет, просто хотелось бы побыстрее сделать маленький кусок, а далее, если пойдет, то еще доделать, то тут лучше взять готовое. Это, естественно, моё мнение.
На тему сложной штуки — абсолютно нет, он скорее запутанный.
Я предлагал сохранять для каждой Activity не всё, а только State. Это не отменяет того, что, скорее всего, потребуется еще хранить сам алгоритм работы, параметры по умолчанию и т. д.
То есть, если UnloadOnIdle == true, то будут вот такие особенности:
1. В памяти больше Activity, а это падение производительности (см. график в статье) для остальных + заблокировано большее количество Workflow Instance, чем следует. Кстати, это тоже падение производительности. И не забываем про блокировку, ограниченную во времени, то есть мы не может совсем долго тянуть с Unload.
2. Нам потребуется вызывать метод Unload самостоятельно. На деле это очень и очень плохая идея, так как сделан он крайне криво. Дело в том, что если Workflow Instance не находится в памяти, то он сначала будет Load, а потом — Unload. Двойной Load для Instance приводит к порче памяти, а такое возможно, если загрузка идет в нескольких потоках (еще одна проблема Microsoft Workflow, кстати). Более того, если Workflow Instance удален (то есть как-то остановился, не важно даже как), в памяти его нет, а мы сделали Unload, то сначала произойдет Load, а, раз Workflow Instance отсутствует в памяти и в базе, мы получаем исключение на ровном месте. А дальше, с малой долей вероятности (я не смог отследить правильную последовательность действий), мы еще и получим ломаный Workflow Instance в памяти, который не может быть выгружен, и из-за которого не будет останавливаться Workflow Runtime.
Всё это мы, конечно, не сразу получали, а постепенно, экспериментальным путем. В общем, я бы не советовал вручную рулить загрузкой и выгрузкой.
1. Используйте класс Workflow Runtime, чтобы сообщать об Event'ах, запускать процессы и останавливать их
2. Можно хостить Workflow как web-сервис (более того, можно это делать на разных серверах). Тогда общение будет происходить через WCF
В целом, схема такая:
1. Запускаете рабочий процесс. Он работает, вызывает сервисы, посылает письма, ждет — в общем, что-то делает.
2. Если Вам требуется, иногда, ждать действий пользователя, то поддерживаете Event Model. Ну то есть идете дальше, если приходит этот самый Event.
Например, если у Вас web приложение, то event можно посылать в момент обработки пользовательского запроса. Дальше Workflow крутанется и как-нибудь отреагирует. Например, если требуется проверять, что пользователь правильно заполнил форму, можно использовать Workflow: оно сначала проверит, что всё более-менее правильно, потом отправит письма и т.д. Программист создает только отдельные кубики, аналитик их соединяет и настраивает.
Для аналитика:
В случае прототипа можно остановиться на Visual Studio Express, в котором можно создать дизайн. Для реальной платформы корректнее всего потом создать свой дизайнер, чтобы избежать разного рода code-injection (так как if activity содержит, например, код для выполнения). Плюс стандартный дизайнер далеко не самый удобный. Самое главное — чтобы в конце получался строчка с xaml с бизнес-процессом.
Для пользователя:
По идее, он вообще не должен особо видеть, что работает внутри. Он должен четко знать, что на его действие А система реагирует действием Б. И всё. А уже как оно происходит не особо важно. Разве что заказчик должен знать, что процесс всегда можно поменять лично для него.
Однако я не нашёл способа, как, например, избавиться от проблемы некорректной загрузки (то есть загрузки по 1000 элементов за раз). У вас была такая задача?
WF 3.0 идет как отдельная библиотека в .Net 3.0: %systemdrive%:\Windows\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation. То, что он появился изначально в другой технологии, не так важно начиная уже с .Net 3.0, так как библиотеки Workflow не линкуются.
Про SharePoint 2013 — я не про него писал, а про то, какие интересные моменты от использования Workflow в своих приложения. Так-то да, нам следует взять объект Workflow Runtime и все запуски делать через него.
На тему параллельной работы: блокировка объектов происходит функцией RecoverInstanceLocks (я вставил выдержку из кода ниже). Это код WF 4. В предыдущей версии стиль тот же, просто нет top 1000. Как Вы понимаете, всё хорошо только в случае, если у нас все задачи очень быстрые. Более того, через две минуты придет новая порция данных, даже если эти еще не обработанные. Что в паре с нелинейной асимптотикой производительности дает плохой результат.
Про сохранение — я привел в пример delay activity, когда ждать следует 0 секунд. Зачем здесь сохраняться?
Про функцию зеркалирования не знал, огромное спасибо. Изучу.
С билдами его легко интегрировать: см. соседние комментарии. На создание тестов будет потрачено значительно больше времени, чем на подобную интеграцию.
Преимущество FitNesse в ином: Вы можете разделить разработку самих тестов и создание API. На деле это действительно получается (у нас получалось), ведь тестировщик может использовать еще несуществующие функции при создании тестов (запустить он их не сможет). Допустим, нам нужна функция переименования пользователя. Тестировщик напишет (верстка едет, табличка не получилась..):
|Change user|Some User|
|Property Name|New Value|
|First Name|John|
Тест не запустится — функции-то нет. И создается баг в трекере: требуется функция…. У нас получалось создавать тесты параллельно с API, что довольно круто.
Продолжая сравнение: SpecFlow , как я понял, требует установленной Visual Studio для разработки, тестирования и запуска, верно? А это еще + $1 000 за каждую платформу. Это не большие деньги для компании, но сам факт наличия дополнительных трат может стать серьезной преградой.
Однако если исключить меркантильность и то, что студия кушает больше ресурсов, чем браузер, то получаем, что серьезных преимуществ у FitNesse нет (разве что комьюнити, что не всегда уж и надо). На тему удобства мне сложно что-то говорить, так как я не работал со SpecFlow. Скорее всего, у них есть подсветка кода, выполнение на билд сервере, а не локально (не настраивать же тестировщикам платформы локально?) и всё то, что требуется.
Решается данная недоработка просто: FitNesse можно запустить в режиме «выполнить всё и завершиться». Ну то есть Rest он выполнит сам у себя. Я привел в статье пример, но, чтобы не искать: java.exe -jar «fitnesse-standalone.jar» -d D:\ -c «MyTests?suite&format=xml» -b «d:\builds\TestsResults.xml»
Аргументы:
1. Путь к Jar файлу.
2. -d + путь к папке, в которой лежит fitNesseRoot
3. Наша Rest комманда
4. -b + путь к результирующему xml файлу.
После этого наш CCNet преобразует xml в красивый html для письма (с подсветкой упавшего и пр.).