#f# #nunit #continuous-integration #nant #jenkins
#f# #nunit #непрерывная интеграция #nant #дженкинс
Вопрос:
Я работаю с командой, которая разрабатывает Java-приложение, используя следующую хорошо зарекомендовавшую себя цепочку инструментов для автоматизированного построения, тестирования и непрерывной интеграции:
- ОС: Ubuntu
- IDE: Eclipse
- Инструменты сборки: Ant
- Платформа тестирования: JUnit
- Управление версиями: Subversion
- Сервер CI: Дженкинс
Типичная задача Дженкинса — получить исходный код Java из Subversion и запустить цели Ant для сборки кода, запуска автоматических тестов и создания артефактов развертывания.
Сейчас мы рассматриваем возможность написания плагина .Net для клиентов Windows для доступа к API нашего приложения из MS Excel. Вероятно, мы напишем его, используя либо C #, либо F # — это первые дни, и мы еще не определились с языком, но F # кажется, что он может предложить некоторые преимущества с точки зрения возможности выражать действия API с помощью DSL на основе комбинатора.
Мы хотели бы выполнить как можно больше этой работы в Linux, используя Mono, и использовать нашу существующую инфраструктуру CI для сборки и тестирования нашего программного обеспечения.
Мое первое впечатление, что набор инструментов будет выглядеть примерно так:
- ОС: Linux
- IDE: Monodevelop / VIM (поддержка Eclipse для Mono и особенно для F #, кажется, отсутствует)
- Инструмент сборки: NAnt
- Платформа тестирования: NUnit
- Управление версиями: Subversion
- Сервер CI: Дженкинс, с плагином NAnt
Есть ли у кого-нибудь опыт разработки с помощью такого рода цепочки инструментов? Два вопроса, на которые я хотел бы получить ответы::
- Каковы основные подводные камни в этом подходе для разработчиков, привыкших к экосистеме Java?
- Существуют ли лучшие альтернативы NAnt и NUnit для построения и запуска автоматических тестов, особенно для F #?
Ответ №1:
Использование F # с MonoDevelop в Linux кажется правильным решением, если вы разрабатываете кроссплатформенные или серверные приложения, которые можно разрабатывать на Linux (и иногда тестировать на Mac / Win).
Однако я не думаю, что вы сможете разработать плагин Excel для Linux, если вы ориентируетесь на пользователей Windows. Вам обязательно нужно будет запустить Excel в Windows, и для тестирования вам, вероятно, также потребуется выполнить (часть) разработки в Windows (я полагаю, интеграция — сложная часть, хотя вы могли бы разработать и протестировать некоторые основные функции в Linux).
В Windows вы можете использовать бесплатную оболочку Visual Studio с F #. Интеграция MonoDevelop для F # (надеюсь) довольно хороша, но Visual Studio дает вам, вероятно, лучший опыт, и вам все равно придется использовать Windows для довольно многих задач...
Ответ №2:
Каковы основные подводные камни в этом подходе для разработчиков, привыкших к экосистеме Java?
Вы используете операционную систему Linux для разработки расширения для Excel, которое в первую очередь является Windows. Платформа Mono довольно хороша, но вы можете столкнуться с ошибками — либо с C #, либо с F #. Это не такая большая проблема, как несколько лет назад, но ее стоит рассмотреть. Если вы решите придерживаться платформы Mono / Linux — MonoDevelop — это правильный путь.
Существуют ли лучшие альтернативы NAnt и NUnit для построения и запуска автоматических тестов, особенно для F #?
Взгляните на FsUnit, если вы планируете использовать F #. В нем есть несколько хороших синтаксических утверждений и т. Д. Это дополнение к NUnit, так что вы не окажетесь в неизведанных водах.