Существуют ли какие-либо рамки модульного тестирования, не зависящие от языка? [закрыто]

Я всегда скептически относился к переписыванию рабочего кода - портирование кода не является исключением. Однако с появлением TDD и автоматизированного тестирования гораздо разумнее переписать и реорганизовать код.

Кто-нибудь знает, есть ли инструмент TDD, который можно использовать для портирования старого кода? В идеале вы могли бы сделать следующее:

1. Запишите независимые от языка модульные тесты для старого кода, который проходит (или не проходит, если вы обнаружите ошибки!).
2. Запустите модульные тесты на другой базе кода, которые не пройдут.
3. Напишите код на вашем новом языке, который проходит тесты, не глядя на старый код.

Альтернативой может быть разделение шага 1 на «Записать модульные тесты на языке 1» и «Переносить модульные тесты на язык 2», что значительно увеличивает требуемые усилия и трудно обосновать, если старая кодовая база перестанет поддерживаться после порт (то есть вы не получаете преимуществ от непрерывной интеграции на этой базе кода).

РЕДАКТИРОВАТЬ: Стоит отметить этот вопрос на StackOverflow.

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

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

Если ваше приложение является веб-сервисом, вы можете протестировать его на любом языке, который вам нужен, при условии, что оно поддерживает ваш протокол. Если ваше приложение запускается в браузере, вы можете использовать селен (это первое, что пришло мне в голову, но есть и другие. И т. Д. Могут быть случаи, когда это не сработает, я думаю (может быть, аппаратное обеспечение), все зависит на тип приложения, над которым вы работаете.

Конечно, у вас не будет такого покрытия, как у вас на юнит-тестах (если вы не тратите много времени), но, по крайней мере, у вас будет тестовая привязь.

Я думаю, что ближе всего к вашей идее являются рамки модульного тестирования в экосистемах на основе виртуальных машин, таких как Java VM. По крайней мере, Scala (и я считаю, что Groovy тоже - я не совсем уверен в Clojure) почти идеально совместим с Java. То есть код Scala можно тестировать с помощью JUnit, а код Java - с помощью ScalaTest. Таким образом, вы можете (постепенно или сразу) переписать код Java в Scala и продолжать использовать те же самые старые модульные тесты Java, чтобы проверить его правильность. (Или наоборот - хотя я не могу представить себе вескую причину для перехода с Scala обратно на Java.)

Вероятно, то же самое относится к языкам в .NET CLI, например, C #, F #, ASP.NET et al.

Вне VM / CLR, однако, это сложнее. Теоретически можно скомпилировать модульные тесты и / или тестируемый код на другом языке, таком как C (как это было и является обычным для новых языков, таких как ранний C ++ и т. Д.), Но я не слышал, чтобы кто-нибудь специально пытался это сделать с модульные тесты.

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

Например, инфраструктура для тестирования кода на c ++ должна быть написана на c или c ++. Использование фреймворка, написанного на c ++, возможно, но он не собирается тестировать код ac, если он использует функции c ++.

Методологии меняются, но в моем случае большая часть моих тестов TDD имеет тенденцию к «интегральному тесту», в отличие от «модульного теста». То есть большинство из них тестируют всю программу в почти реальных запросах, проверяя соответствующие ответы.

В некоторых случаях, когда я писал программы, управляемые сетью (в основном протоколы для конкретных приложений), у меня не было под рукой полной инфраструктуры тестирования, которая была бы удобной для работы, поэтому я проводил большую часть тестирования «по сети», в Короче говоря, я написал очень простой клиент на другом языке с общей и простой структурой тестов, и большинство тестов проверяли ответы сервера.

Тем не менее, даже в этих случаях я вводил несколько тестов в реальном приложении, чтобы протестировать некоторые не сетевые компоненты.

Фреймворк для независимого от языка теста - это универсальная тестовая среда, подходящая для приемочного теста (точка зрения), и тестовые случаи в этой среде управляются QA, например, Robotframework