Смешивание java и scala в одном проекте - тесты в scala, core в java

Question

Предположим, что один предпочитает структуру тестирования функционального стиля (например, спецификации) и не нравится те, которые являются отраслевым стандартом для Java (например, JUnit). Является ли хорошей практикой иметь проект Java с тестами unit/integration, написанными только в scala (и остальными проектами, написанными в java)? Существуют ли какие-либо недостатки такого подхода?

Answer 1

У меня есть опыт в этом, мы использовали это раньше.

Недостатки:

1. Scala знания: Для точки зрения разработчика, они не узнают слишком много, если они только пишут SCALA код для проверки, потому что некоторые других функции Scala, как неявный, уровень типа программирование и т. д. не будет хорошо б/у.

2. Тип преобразования: Преобразование типа очень раздражает. Почти вся коллекция Java изменена, как ArrayList, HashMap и т. Д., Но Scala Seq, List, Map, она будет импортирована как неизменная коллекция, поэтому вам нужно все время их конвертировать с помощью Scala.collection.JavaConversion._ , Не говоря уже о том, что другой тип, например BigDecimal в java, вам также нужно его преобразовать.

3. Slow сборник: Если вы используете Specs2, он может относительно увеличить время компиляции, лично я думаю, что он может использовать неявный слишком много, каждый метод испытания должен вернуть MatchResult, этот тип подразумевается неявным образом. Если вы пишете тест без какого-либо совпадения, вы можете увидеть неявную не найденную ошибку. Во всяком случае, компиляция может занять много времени.

4. Отсутствие поддержки IDE, чтобы сделать TDD, я использую IntelliJ 13 Ultimate Edition, в Java, мне нравится делать TDD и это быстро, но в тесте Scala, он не поддерживает это очень хорошо, альт + ввести оленья кожа дать мне слишком много полезных опций

5. Dont пытаются смешивать импорт Java и Scala код, так что сейчас в проекте, Scala код с помощью Java-кода в тестовом пакете, если некоторые импорта тестового кода Java Scala, можно смутить IDE. Intellij недостаточно умен, чтобы скомпилировать первый. У нас есть эта проблема, мы просто вручную компилируем тестовый код Scala, а затем строим проект, но это немного расстраивает.

Я не большой поклонник только с помощью Scala для тестирования. Scala - удивительный язык, предоставляющий так много возможностей, чтобы вы могли написать выразительный и элегантный код.

Несколько предложений за попытку использовать Scala на основном проекте Java (может от темы)

Microservice: Насколько я знаю, мои друзья из основного проекта Java используют microservice в качестве решения для записи Scala-код поверх Java. Однако в некоторых сценариях это может увеличить ненужные затраты на техническое обслуживание.

Jar: вы также можете отделить его, создав проект Scala, а затем упаковать банку, опубликовать в своей компании Nexus, а затем импортировать ее в свой проект Java. Я думаю, что это чистое решение, потому что они оба сидят на вершине JVM, и Dev не будет жаловаться на проблему компиляции.

Я думаю, что другие люди могут иметь подобный опыт, а также, я надеюсь, что смогу узнать его :)

Answer 2

Я сделал это в нескольких проектах, например. используя Spock (groovy), scala-test. Это довольно эффективный способ оценивать, учиться и играть с новыми языками программирования.
Есть ли недостатки? Если ваша команда использует непрерывную интеграцию, возможно, вам нужно потратить некоторое время, чтобы настроить Maven/Gradle, чтобы включить ваши тесты и другие конфигурации, чтобы CI мог ее построить.

Answer 3

Технически это возможно сделать это, но я не думаю, что это правильный путь. Если ваша команда знает/желает изучить scala, тогда они, вероятно, захотят написать весь код в scala, а не только тесты (или, по крайней мере, сделать это для нового кода).
Если команда не знает scala, кривая обучения высока, и поскольку тесты обычно ограничены, они не будут многому научиться у нее.
Если вы пытаетесь прокрасться с помощью тестов scala, вы можете получить обратный эффект.
Есть проблемы с scala (например, сильная поддержка IDE, длинные компиляции, интеграция с сторонними инструментами и т. Д.). ИМХО, стоит заплатить, когда вы развиваетесь в scala, но не ограничены для тестов.

Если вы хотите более функциональный способ написать свои тесты, я рекомендую вам использовать Spock. Это очень хорошая среда тестирования и спецификации Java и Groovy. Поскольку groovy намеревается быть знакомым разработчикам java, они могут чувствовать себя более комфортно с его помощью.
Я начал использовать его раньше, но затем переписал все приложение в scala :)