Инфраструктура модульного тестирования Lotusscript-кода

[Yakov]

Наверное, о модульном тестировании (unit tests) не слышали только глухие и ленивые. Я не буду писать здесь об unit-тестах и TDD, желающие самостоятельно найдут необходимую информацию. Я сам испробовал TDD на нескольких небольших java-проектах. После этого, являясь Lotus-разработчиком, чувствую себя обделенным таким полезным инструментом, как инфрастуктура модульного тестирования для LotusScript-кода.
Поиски xUnit для LS на

Ссылка скрыта от гостей

результатов не дали (кто бы сомневался ), поиск в гугле по фразе "lotusscript unit tests" дал две вразумительные ссылки:

Ссылка скрыта от гостей

и

Ссылка скрыта от гостей

. Но эти инструменты меня не удовлетворили, и я решил создать свой велосипед. За идейную основу был принят пакет JUnit 3.x.
Довольно быстро реализовав базовые механизмы инфрастуктуры (названной, как ни странно, LSUnit), я столкнулся с другими проблемами, которые заставили меня отложить работу над LSUnit на несколько месяцев. Проблемы такие: трудности создания тестовой конфигурации и скорость выполнения тестов. Для каждого тестового метода следует создавать тестовую конфигурацию - набор объектов тестируемой системы. В Лотусе это, естественно, документы. Даже если тестируемая система состоит из высокоуровневых классов, реализующих бизнес-логику, они, в конечном счете, все равно работают с документами. Таким образом, для запуска теста приходится создавать один или несколько документов в базе данных (или копировать их из некого хранилища тестовых документов), обновлять индексы представлений и т. п. А все это создает вторую проблему - скорость выполнения тестов. Да и скорость работы с "настоящими" документами (чтение/запись значений полей) значительно ниже скорости работы с объектами в памяти.
Поэтому однажды было принято решение создать библиотеку подставных объектов, которые имитировали бы работу NotesXXX классов. Библиотека была названа FakeObjects, то есть "поддельные объекты". Сейчас эта библиотека совсем небольшая, она постоянно расширяется и дополняется по мере необходимости. Но и сейчас она уже покрывает потребности небольшого проекта, на котором я ее разрабатываю. Более детальное описание библиотеки вы найдете в приложенном архиве.
Что дает эта библиотека? В первую очередь, скорость выполнения тестов. 100 тестов выполняются не более 0,1 секунды. Во-вторых, полный контроль над тестовой конфигурацией. Библиотека позволяет создать необходимый минимум тестовых данных (минимальное количество документов с полями, нужными в конкретном тесте), изменить поведение нужным образом (например, создать ситуацию, когда document.save() возвращает false).
Но, естественно, существуют и недостатки, некоторые из которых могут вызвать очень серьезные труднности. Но эти трудности, при желании, могут быть преодолены.
Во-первых, придется отказаться от строгой типизации переменных, содержащих объекты NotesXXX, в пользу Variant. Это нужно для того, чтобы можно было подменить Notes-объекты поддельными. Это серьезная проблема, ведь компилятор теперь не укажет на ошибку. Но если весь код будет покрыт тестами, то все подобные ошибки будут отловлены.
Следствием использования Variant'ов будет некоторое уменьшение скорости выполнения кода. Но, по-моему, несколько микросекунд не большая цена за уверенность в коде.
Во-вторых, невозможно сымитировать необязательные аргументы. Приходится либо использовать полный список аргументов, либо ограничиваться необходимым минимумом. К примеру, метод Save класса NotesDocument имеет три аргумента, последний из которых необязательный. Я не помню случая, когда бы этот аргумент использовался, поэтому в библиотеке FakeObjects метод Save класса FakeDocument имеет только два аргумента. И в тестируемой системе придется использовать только такой вид метода Save.
В-третьих, не все методы Notes-классов правильно вызываются, если переменная, содержащая объект, имеет тип Variant. Я пока обнаружил один такой метод - NotesDatabase.Search. Подробности - в приложенном архиве. Там же описана и другая необходимость создания test-specific кода. При использовании ООП и коротких методов эти трудности также решаются.

Библиотеки LSUnit и FakeObjects выпускаются в Public Domain ("общественное достояние"). Вы можете делать с этими библиотеками что угодно. Неимущественные авторские права, естественно, остаются за мной. Автор не предоставляет никаких гарантий и отказывается от любой ответственности.

И, напоследок, две книги:

1. Джерард Месарош. Шаблоны тестирования xUnit. Рефакторинг кода тестов
Издательство: Вильямс, 2009 г., Твердый переплет, 832 стр., Тираж: 1000 экз.
ISBN 978-5-8459-1448-4, 978-0-13-149505-0

В этой книге есть все, что нужно знать об автоматизированном тестировании.

2. Майкл К. Физерс. Эффективная работа с унаследованным кодом
Издательство: Вильямс, 2009 г., Твердый переплет, 400 стр., Тираж: 1000 экз.
ISBN 978-5-8459-1530-6, 0-13-117705-2

Самое ценное в этой книге - это определение унаследованного кода. В ней сказано, что унаследованный (legacy) код - это код, не покрытый тестами. Ну и в качестве бонуса - несколько приемов для ввода унаследованного кода в инфрастуктуру тестирования.


Задавайте вопросы, постараюсь на них ответить.

 

[Akupaka]

Задавайте вопросы, постараюсь на них ответить

научи, пожалуйста, уметь так же относится к делу!

 

[K-Fire]

Можете описать реальный пример, где Unit-тест оказался более полезен, чем например, ручной проход по коду в дебаггере? Во всех книжках, везде везде пишут что Unit-тестирование это фишка must have, но нужность этого дела в лотусе от меня ускользает.

 

[Yakov]

научи, пожалуйста, уметь так же относится к делу!

Так же это как?

K-Fire, вот пример.
Есть некий настроечный документ. Документ кроме всего прочего содержит путь к папке для временных файлов. Этот путь вводится пользователем (администратором) вручную. Есть класс-обертка над этим настроечным документом. Хочется использовать конструкцию вида settings.getTempPath() + fileName и не задумываться над тем, что вписано в поле настроечного документа. Иными словами, поле может быть пустым, может содержать путь вида "C:\Temp\Images", может содержать путь вида "C:\Temp\Images\". И в любом случае конструкция settings.getTempPath() + fileName должна возвращать валидное имя файла вида "0001.jpg" или "C:\Temp\Images\0001.jpg"
Попробуем реализовать класс Settings.

0. Создаем классы Settings и TestSettings:

Public Class Settings

Public Sub New(document As Variant)

End Sub

Public Function getTempPath() As String

End Function

End Class

Public Class TestSettings As TestCase

Private document As Variant

Public Sub setUp()
Set document = New FakeDocument(Nothing)
End Sub

End Class

1. Пишем первый тест:

	Public Sub testGetTempPath_regularPath()
Call document.replaceItemValue("TempPath", "c:\temp\images\")
Set settings = New Settings(document)
Call assertEquals("regular path", "c:\temp\images\", settings.getTempPath())
End Sub

Запускаем, тест не проходит: "expected: STRING<c:\temp\images\> but was: STRING<>". Дорабатываем класс Settings:

Public Class Settings

Private tempPath As String

Public Sub New(document As Variant)
tempPath = document.getItemValue("TempPath")(0)
End Sub

Public Function getTempPath() As String
getTempPath = tempPath
End Function

End Class

Теперь тест проходит.

2. Пишем второй тест:

	Public Sub testGetTempPath_noSlash()
Call document.replaceItemValue("TempPath", "c:\temp\images")
Set settings = New Settings(document)
Call assertEquals("no slash", "c:\temp\images\", settings.getTempPath())
End Sub

Запускаем, тест не проходит: "expected: STRING<c:\temp\images\> but was: STRING<c:\temp\images>". Дорабатываем класс Settings:

	Public Sub New(document As Variant)
tempPath = document.getItemValue("TempPath")(0)
If Right(tempPath, 1) <> "\" Then
tempPath = tempPath + "\"
End If
End Sub

Теперь тест проходит.

3. Пишем третий тест:

	Public Sub testGetTempPath_emptyPaht()
Set settings = New Settings(document)
Call assertEquals("empty path", "", settings.getTempPath())
End Sub

Тест не проходит: "expected: STRING<> but was: STRING<\>". Дорабатываем класс Settings:

	Public Sub New(document As Variant)
tempPath = document.getItemValue("TempPath")(0)
If tempPath <> "" And Right(tempPath, 1) <> "\" Then
tempPath = tempPath + "\"
End If
End Sub

Теперь все тесты успешно проходят. Задача решена. Нет ни единой лишней строчки, дебаггер ни разу не запускался.

Теперь решим обратную задачу. Есть код класса Settings, приведенный в третьем тесте. Нужно его протестировать. Написание и запуск трех тестов займет минуты 3-4. А сколько времени займет ручное тестирование с изменением настроечного документа и прогоном какого-либо тестового агента? А если этот агент должен забрать из указанного каталога файлы, присоединить их к новому документу, и выслать этот документ куда-либо? Это придется три раза подложить файлы и три раза проверить приход документа по адресу? А сколько времени займет прогон этого агента под дебаггером?

 

[ToxaRat]

однако Тоха почитает
и пока он читал у него появились вопросы и предложения

Yakov
не подскажешь ли мне следующее, в списке агентов кроме запуска есть пункт Test - который тестит но ничего не меняет в базе, случаем они не делают подмену класса Doc, особенно метода Doc.Save так же как и ты?
мне всегда было интересно как выдернуть их Тест для себя, к примеру я банально хочу пройтись по всему коду и ВСЁ запустить, подскажешь куда копать?
как по мне банальный вызов всего, что шевелится тоже недурной способ протестировать всё и тут без подмены классов не обойтись, а если еще и удастся сохранять где-то промежуточные данные было бы чудно...

 

[Yakov]

в списке агентов кроме запуска есть пункт Test

Где это?

 

[ToxaRat]

получить бі полній инструментарий к єтому...