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

@Yokov · Регистрация: 08.02.2007

Студворк — интернет-сервис помощи студентам

Наверное, о модульном тестировании (unit tests) не слышали только глухие и ленивые. Я не буду писать здесь об unit-тестах и TDD, желающие самостоятельно найдут необходимую информацию. Я сам испробовал TDD на нескольких небольших java-проектах. После этого, являясь Lotus-разработчиком, чувствую себя обделенным таким полезным инструментом, как инфрастуктура модульного тестирования для LotusScript-кода.
Поиски xUnit для LS на http://xprogramming.com/software результатов не дали (кто бы сомневался ), поиск в гугле по фразе "lotusscript unit tests" дал две вразумительные ссылки: http://ca.geocities.com/nshenoy0424@rogers.../downloads.html и http://www.openntf.org/Projects/pmt.nsf/Pr...nit%20Framework. Но эти инструменты меня не удовлетворили, и я решил создать свой велосипед. За идейную основу был принят пакет 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) код - это код, не покрытый тестами. Ну и в качестве бонуса - несколько приемов для ввода унаследованного кода в инфрастуктуру тестирования.

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

@okupoko · 28.09.2009, 19:50

Сообщение от Yakov

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

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

@K-Fyry · 28.09.2009, 20:31

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

@Yokov · 28.09.2009, 22:45

Сообщение от Akupaka

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

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

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:

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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(Nothyng)
End Sub
 
End Class

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

Code
1
2
3
4
5
    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:

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
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. Пишем второй тест:

Code
1
2
3
4
5
    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:

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

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

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

Код (Text):
Public Sub testGetTempPath_emptyPaht()
Set settings = New Settings(document)
Call assertEquals("empty path", "", settings.getTempPath())
End Sub
Тест не проходит: "expected: STRING<> but was: STRING<\>". Дорабатываем класс Settings:

Код (Text):
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. А сколько времени займет ручное тестирование с изменением настроечного документа и прогоном какого-либо тестового агента? А если этот агент должен забрать из указанного каталога файлы, присоединить их к новому документу, и выслать этот документ куда-либо? Это придется три раза подложить файлы и три раза проверить приход документа по адресу? А сколько времени займет прогон этого агента под дебаггером?

@ToxoRot · 30.09.2009, 13:05

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

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

@Yokov · 30.09.2009, 13:16

Сообщение от ToxaRat

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

Где это?

@ToxoRot · 30.09.2009, 14:36

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

Новые блоги и статьи Все статьи Все блоги /
Перемещение выделенных строк ТЧ из одного документа в другой Maks 30.03.2026 Реализация из решения ниже выполнена на примере нетипового документа "ВыдачаОборудованияНаСпецтехнику" с единственной табличной частью "ОборудованиеИКомплектующие" разработанного в конфигурации КА2. . . .	Functional First Web Framework Suave DevAlt 30.03.2026 Sauve. IO Апнулись до NET10. Из зависимостей один пакет, работает одинаково хорошо как в режиме проекта так и в интерактивном режиме. из сложностей - чисто функциональный подход. Решил. . .	Автоматическое создание документа при проведении другого документа Maks 29.03.2026 Реализация из решения ниже выполнена на нетиповых документах, разработанных в конфигурации КА2. Есть нетиповой документ "ЗаявкаНаРемонтСпецтехники" и нетиповой документ "ПланированиеСпецтехники". В. . .	Настройка движения справочника по регистру сведений Maks 29.03.2026 Решение ниже реализовано на примере нетипового справочника "ТарифыМобильнойСвязи" разработанного в конфигурации КА2, с целью учета корпоративной мобильной связи в коммерческом предприятии. . . .
Автозаполнение реквизита при выборе элемента справочника Maks 27.03.2026 Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .	Сумматор с применением элементов трёх состояний. Hrethgir 26.03.2026 Тут. https:/ / fips. ru/ EGD/ ab3c85c8-836d-4866-871b-c2f0c5d77fbc Первый документ красиво выглядит, но без схемы. Это конечно не даёт никаких плюсов автору, но тем не менее. . . всё может быть. . .	Автозаполнение реквизитов при создании документа Maks 26.03.2026 Программный код из решения ниже размещается в модуле объекта документа, в процедуре "ПриСозданииНаСервере". Алгоритм проверки заполнения реализован для исключения перезаписи значения реквизита,. . .	Команды формы и диалоговое окно Maks 26.03.2026 1. Команда формы "ЗаполнитьЗапчасти". Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. В качестве источника данных. . .

@Yokov 0 / 0 / 0 Регистрация: 08.02.2007 Сообщений: 206

	Инфраструктура модульного тестирования Lotusscript-кода 28.09.2009, 16:37. Показов 15490. Ответов 6 Метки нет (Все метки) Наверное, о модульном тестировании (unit tests) не слышали только глухие и ленивые. Я не буду писать здесь об unit-тестах и TDD, желающие самостоятельно найдут необходимую информацию. Я сам испробовал TDD на нескольких небольших java-проектах. После этого, являясь Lotus-разработчиком, чувствую себя обделенным таким полезным инструментом, как инфрастуктура модульного тестирования для LotusScript-кода. Поиски xUnit для LS на http://xprogramming.com/software результатов не дали (кто бы сомневался ), поиск в гугле по фразе "lotusscript unit tests" дал две вразумительные ссылки: http://ca.geocities.com/nshenoy0424@rogers.../downloads.html и http://www.openntf.org/Projects/pmt.nsf/Pr...nit%20Framework. Но эти инструменты меня не удовлетворили, и я решил создать свой велосипед. За идейную основу был принят пакет 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) код - это код, не покрытый тестами. Ну и в качестве бонуса - несколько приемов для ввода унаследованного кода в инфрастуктуру тестирования. Задавайте вопросы, постараюсь на них ответить. 0

@K-Fyry 0 / 0 / 0 Регистрация: 15.12.2006 Сообщений: 641
	28.09.2009, 20:31
	Можете описать реальный пример, где Unit-тест оказался более полезен, чем например, ручной проход по коду в дебаггере? Во всех книжках, везде везде пишут что Unit-тестирование это фишка must have, но нужность этого дела в лотусе от меня ускользает. 0

@ToxoRot 0 / 0 / 0 Регистрация: 04.11.2007 Сообщений: 3,019
	30.09.2009, 13:05
	однако Тоха почитает и пока он читал у него появились вопросы и предложения Yakov не подскажешь ли мне следующее, в списке агентов кроме запуска есть пункт Test - который тестит но ничего не меняет в базе, случаем они не делают подмену класса Doc, особенно метода Doc.Save так же как и ты? мне всегда было интересно как выдернуть их Тест для себя, к примеру я банально хочу пройтись по всему коду и ВСЁ запустить, подскажешь куда копать? как по мне банальный вызов всего, что шевелится тоже недурной способ протестировать всё и тут без подмены классов не обойтись, а если еще и удастся сохранять где-то промежуточные данные было бы чудно... 0

@ToxoRot 0 / 0 / 0 Регистрация: 04.11.2007 Сообщений: 3,019
	30.09.2009, 14:36
	получить бі полній инструментарий к єтому... 0