Что (скидка) преимущества записи модульных тестов на другом языке к коду?

Одна очевидная потенциальная проблема - запутывающая процедура отладки. Я лично не пробовал выполнять отладку на разных языках в .NET - что произойдет, если вы войдете в код C # из IronPython?

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

Я большой поклонник языков Iron, но их использование для тестирования статически скомпилированного кода имеет существенные недостатки. Тестирование Ruby / Python с помощью Ruby / Python отлично работает, т.е. вы можете подделывать объекты любым количеством способов. Но тестирование C # с Ruby / Python может привести к большей сложности, чем можно было бы желать.

Рассмотрим сценарий, в котором вы пишете проект ASP MVC, в котором вы хотите подделать тип браузера, отправляющего запрос к контроллеру. В C # вы можете смоделировать это следующим образом (используя Moq):

var fakeRequest = new Moq.Mock<System.Web.HttpRequestBase>();
fakeRequest.Setup(request => request.Browser.Type).Returns("Fake");

В IronRuby это будет выглядеть примерно так:

class FakeBrowser < HttpBrowserCapabilitiesBase
  def type
    "Fake"
  end
end

class FakeRequest < HttpRequestBase
  def browser
    FakeBrowser.new
  end
end

Чем глубже контекст, который нужно обмануть, тем сложнее он становится. В C # фреймворк mocking автоматически подбирает подтипы, но в динамическом языке вам, к сожалению, предстоит много работы. Имитирующие библиотеки, такие как PyMock или Mocha, не будут работать для подобных тестов, потому что тестируемый код имеет строгие зависимости типа, а фальшивые объекты, созданные фреймворками Ruby / Python, не будут соответствовать этим зависимостям. Мне бы хотелось, чтобы ситуация улучшилась по мере развития и IronRuby, и IronPython, но сейчас история тестирования C # не так хороша.

Если я ошибаюсь, я бы хотел поправиться. =)

При создании API или библиотеки, Я часто предоставляю модульные тесты как форму документации о том, как лучше всего использовать API или библиотеку. Большую часть времени, когда я создаю библиотеку C #, я доставляю ее клиенту, который будет писать код C # для использования библиотеки.

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

np.core.records.fromrecords(r.tolist()+[(5,'cc',43.)])

Тем не менее, он разбивается, на этот раз по строкам. Может лучше?

Это станет еще более интересным, если вы выйдете за рамки «модульных» тестов на тесты на всех уровнях, где конкретные возможности конкретных языков могут дать преимущества при создании

Главный вопрос заключается в том, перевешивают ли преимущества недостатки ... и это, вероятно, отчасти зависит от конкретного случая.

Самый большой компромисс был бы, если бы кто-то смотрел на использование модульных тестов, чтобы выяснить, как может выполняться определенное действие, написание его на другом языке усложнило бы использование. Также вам нужно будет сделать ваш код C # совместимым с CLS.

Главный недостаток, на мой взгляд, это ремонтопригодность. Если вы пишете код на C #, ваша команда разработчиков знает этот язык, как и новые сотрудники. Вам нужна многофункциональная команда разработчиков.

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

Вам также необходимо переключаться между синтаксисами во время написания кодов / тестов - это немного мешает.

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

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

Я согласен с другими ответами, что есть недостатки, но меня удивляет, что так мало говорили о преимуществах.

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