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

1
Michał Urbaniak 22 Сен 2014 в 19:40
Если ваша команда готова к этому, то дерзайте.
 – 
Chris K
22 Сен 2014 в 19:41
2
Большинство проблем взаимодействия Scala/Java возникает при переходе Java->Scala. Scala->Java довольно безупречна.
 – 
Chris K
22 Сен 2014 в 19:42

3 ответа

Лучший ответ

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

Недостатки:

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

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

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

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

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

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

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

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

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

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

1
Xiaohe Dong 23 Сен 2014 в 05:35

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

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

1
roterl 24 Сен 2014 в 16:59

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

0
sol4me 22 Сен 2014 в 20:05