Grails тестирует пользовательские ограничения проверки роли пользователя с помощью Spring Security Core Plugin - PullRequest
Новая
       17

Grails тестирует пользовательские ограничения проверки роли пользователя с помощью Spring Security Core Plugin

1 голос
/ 01 мая 2011

Я уверен, что это довольно распространенная ситуация. Я использую плагин Spring Security Core и хочу создать модель домена, в которой Person ограничен определенными ролями: 

class Workgroup {

Person manager
...

 static constraints = {
    manager(validator: {mgr ->
            // it feels like there should be a more elegant, groovy way of doing this.
            def auths = mgr.getAuthorities();
            def returny = false
            auths.each {
                if(it.authority == 'ROLE_MANAGER')
                {
                    returny = true
                }
            }
            return returny
        })
}

}

Этот тест проваливается как mofo: 

void testInvalidManager() {
    def nick = new Person(username:'Nick')
    def nonManagerRole = new Role(authority:'ROLE_EMPLOYEE')
    UserRole.create(nick,nonManagerRole)
    def awesome = new Workgroup(name:'mooCows', manager:nick)
    mockForConstraintsTests(Workgroup, [awesome])
    assertFalse awesome.validate()
    assertEquals "validator", awesome.errors["manager"]
}

testInvalidManager Ошибка Нет подписи метода: users.UserRole.save () применима для типов аргументов: (java.util.LinkedHashMap) значения: [[flush: false, insert: true]] Возможные решения: wait (), any (), wait (long), use ([Ljava.lang.Object;), isCase (java.lang.Object), каждый (groovy.lang.Closure)

groovy.lang.MissingMethodException: Нет сигнатуры метода: users.UserRole.save () применим к типам аргументов: (java.util.LinkedHashMap) значения: [[flush: false, insert: true]] Возможные решения: wait (), any (), wait (long), use ([Ljava.lang.Object;), isCase (java.lang.Object), каждый (groovy.lang.Closure) at users.UserRole.create (UserRole.groovy: 32) at users.UserRole.create (UserRole.groovy) at users.UserRole $ create.call (Неизвестный источник) at users.WorkgroupTests.testInvalidManager (WorkgroupTests.groovy: 17)

Это лучше охватывается интеграцией, чем модульным тестированием? Нужно ли издеваться над UserRole (если да, то как?)? Как обычно проводятся тесты такого типа?

1 Ответ

2 голосов
/ 01 мая 2011

UserRole.create() вызывает save(), поэтому вам нужно использовать mockDomain() вместо просто mockForConstraintsTests().

Но это только в том случае, если вы согласны с тестированием модели домена с помощью имитаций, которые яникогда бы не сделал.Поддержка имитации в Grails должна использоваться при тестировании контроллеров или других классов, которые используют классы домена, но не должны беспокоиться о реальном постоянстве, создании базы данных (даже в памяти) и т. Д. Удаляя эту зависимость, вы концентрируетесь натекущий уровень, полагая, что другой уровень уже должным образом протестирован.Но когда вы используете mocking для тестирования доменных классов, вы на самом деле просто тестируете mocking framework.Поэтому я всегда использую интеграционные тесты для классов доменов, чтобы они работали с реальной базой данных.

Чтобы ответить на неявный вопрос из вашего примера кода, я бы написал ограничение как 

static constraints = {
   manager validator: { mgr ->
      mgr.authorities.find { it.authority == 'ROLE_MANAGER' } != null
   }
}

.проблема с его объемом заключается в том, что вы используете each (), когда предпочтителен регулярный цикл for, поскольку вы можете вернуться из цикла for.Используйте each () только тогда, когда вы действительно хотите вызывать замыкание в каждом экземпляре.Вот тот, который менее интересен, чем другой, но использует цикл for: 

static constraints = {
   manager validator: { mgr ->
      for (auth in mgr.getAuthorities()) {
         if (it.authority == 'ROLE_MANAGER') {
            return true
         }
      }
      return false
   }
}
...