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

Тема в разделе "Lotus - Программирование", создана пользователем Yakov, 29 сен 2009.

Статус темы:
Закрыта.
  1. Yakov

    Yakov Гость

    Наверное, о модульном тестировании (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) код - это код, не покрытый тестами. Ну и в качестве бонуса - несколько приемов для ввода унаследованного кода в инфрастуктуру тестирования.


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

    Вложения:

    • LSUnit.zip
      Размер файла:
      11,2 КБ
      Просмотров:
      26
  2. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    научи, пожалуйста, уметь так же относится к делу! :)
     
  3. K-Fire

    K-Fire Гость

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

    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:

    Код (Text):
    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. Пишем первый тест:

    Код (Text):
        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:

    Код (Text):
    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. Пишем второй тест:

    Код (Text):
        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:

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

    ToxaRat Чёрный маг
    Lotus team

    Регистрация:
    6 ноя 2007
    Сообщения:
    3.046
    Симпатии:
    18
    однако Тоха почитает :)
    и пока он читал у него появились вопросы и предложения

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

    Yakov Гость

    Где это?
     
  7. ToxaRat

    ToxaRat Чёрный маг
    Lotus team

    Регистрация:
    6 ноя 2007
    Сообщения:
    3.046
    Симпатии:
    18
    получить бі полній инструментарий к єтому...
     

    Вложения:

    • testagent.JPG
      testagent.JPG
      Размер файла:
      16,4 КБ
      Просмотров:
      62
Статус темы:
Закрыта.

Поделиться этой страницей