Модульное тестирование аспектно-ориентированных функций - PullRequest
Новая
       10

Модульное тестирование аспектно-ориентированных функций

4 голосов
/ 08 марта 2010

Я хотел бы знать, что бы вы предложили, как лучший способ для модульного тестирования аспектов аспектно-ориентированных приложений (ну, возможно, это не лучшее название, но это лучшее, что я смог придумать :-)) такие как логирование или безопасность?

Эти вещи являются вездесущими в приложении, так как их правильно проверить?

например. скажу, что я пишу Cherrypy веб-сервер на Python. Я могу использовать декоратор, чтобы проверить, есть ли у вошедшего в систему пользователя разрешение на доступ к данной странице. Но тогда мне нужно было бы написать тест для каждой страницы, чтобы увидеть, работает ли он нормально (или больше хотелось бы увидеть, что я не забыл проверить разрешения безопасности для этой страницы).

Это может быть (с акцентом на, может быть) терпимым, если ведение журнала и / или безопасность были реализованы во время "обычной бизнес-реализации" веб-сервера. Однако безопасность и ведение журнала обычно добавляются в приложение как последствие (или, может быть, это только мой опыт, мне обычно дают сервер, а затем просят реализовать модель безопасности :-)).

Любые мысли по этому поводу очень приветствуются. В настоящее время я «решил» эту проблему, ну, в общем-то, не проверяя ее вообще. Спасибо.

Ответы [ 3 ]

1 голос
/ 09 мая 2010

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

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

Что касается регистрации, не совсем понятно, что вы хотите проверить конкретно. В любом случае, почему невозможно заблокировать функциональность регистрации и проверить, что там происходит?

0 голосов
/ 11 марта 2010

Мой ответ - для конкретного примера, который вы приводите, а не для возможных проблем с безопасностью на болтах. Декораторы - это просто обычные функции, и вы можете проверить их как таковые. Например: 

# ... inside included module ...
def require_admin(function):
    if (admin):
        return function
    else:
        return None

@require_admin
def func1(arg1, arg2):
    pass

# ... inside unit test ...
def test_require_admin(self):
    admin = False
    f = lambda x: x
    g = require_admin(f)
    assert_equal(g, None)

    admin = True
    g = require_admin(f)
    assert_equal(g, f)

Примечание: это действительно ужасный способ проверки безопасности, но он дает представление о тестировании декораторов. Это одна из приятных вещей в Python: она действительно последовательна. Следующие выражения эквивалентны: 

@g
def f(x):
    return x

и 

def f(x):
    return x
f = g(f)
0 голосов
/ 08 марта 2010

Ну ... посмотрим. По моему мнению, здесь вы тестируете три разные вещи (извините за «жаргон Java AOP»):

  1. функции, реализуемые перехватчиками (то есть методы, реализующие функции, активированные в точках среза)
  2. охват фильтров (т. Е. Правильно ли активированы намеченные точки отсечки или нет)
  3. взаимодействие между точками среза и перехватчиками (с побочными эффектами)

Вы проводите модульное тестирование (строго говоря), если вы можете обрабатывать эти три слоя отдельно. Вы можете на самом деле юнит-тест первого; Вы можете использовать инструмент покрытия и некоторое приложение скелета с фиктивными объектами для проверки второго; но третье - это не совсем модульное тестирование, поэтому вам, возможно, придется настроить тестовую среду, разработать комплексный тест и написать несколько сценариев для ввода данных в ваше приложение и сбора результатов (если это было веб-приложение, вы могли используйте Selenium, например).

...