2014-08-27 2 views
1

Я пишу testcases для метода с оленьей кожей возвращают никаких значений, например, для:Запуск testcases в golang во время исключения

func GetByNameReturnNull(serName string) 
{ 
//Logic 
} 

Моего testcasefile является myTest.go, который имеет два параметра, один вызывая метод с недопустимым вводом и вызов метода с допустимым вводом.

func Test1(t *testing.T) { 
    GetByNameReturnNull("Invalid") 
} 


func Test2(t *testing.T) { 

    GetByNameReturnNull("valid") 
} 

Итак, первый TestCase потерпит неудачу и бросить исключение, я не могу справиться с этим обычным способом, как,

«проверить ERR из возвращенного метода, так как метод оленьей кожи возвращать что-либо вообще. Когда я выполнить команду,

$go test ./... -v 

второй TestCase не будет выполняться из-за исключением первого.

Таким образом, без изменения какой-либо логики в базовый методе (GetByNameReturnNull), чтобы вернуть ERR или что-нибудь, есть ли способ справиться с таким сценарием в файле тестового сам для печати

1 fail 1 pass in the output? 
+1

Если мы предположим, что эта функция 'GetByNameReturnNull' не может быть изменен, чтобы вернуть ошибку? Если он может создать ошибку, он должен действительно вернуть его. – Intermernet

+1

Если да, пожалуйста, посмотрите http://blog.golang.org/defer-panic-and-recover – Intermernet

+1

Я также не хочу откладывать тестовые окна, он должен выполнять тестовые строки в последовательности, например test1, test2, test3 , и, наконец, если какой-либо из тестов завершится неудачей, он должен вернуть 1 проход 2, предположим, что если все тестовые проходы проходят, выход должен быть 3-х прохода ... – user1907849

ответ

4

@VonC верен, нет возможности автоматически обрабатывать его, однако вы можете просто сделать обертку и вызвать ее в каждом тесте.

Таким образом, вам не нужно использовать глобальную переменную для отслеживания тестов.

Пример:

func logPanic(t *testing.T, f func()) { 
    defer func() { 
     if err := recover(); err != nil { 
      t.Errorf("paniced: %v", err) 
     } 
    }() 
    f() 
} 

func Test1(t *testing.T) { 
    logPanic(t, func() { 
     GetByNameReturnNull("invalid") 
    }) 
    //or if the function doesn't take arguments 
    //logPanic(t, GetByNameReturnNull) 
} 

func Test2(t *testing.T) { 
    logPanic(t, func() { 
     GetByNameReturnNull("valid") 
    }) 
} 
+1

Хорошая идея, более практичная, чем мой ответ. +1 – VonC

3

Вы не должны видеть «1 обанкротиться» , если вы ожидаете, что ваш тест будет паниковать.
Вы должны увидеть, что оба теста успешны.

Вместо этого, вы должны проверить конкретно случай паники, как описано, например, в «Understanding Defer, Panic and Recover»:

func TestPanic(t *testing.T) error { 
    defer func() { 
     fmt.Println("Start Panic Defer") 
     if r := recover(); r != nil { 
      fmt.Println("Defer Panic:", r) 
     } else { 
      t.Error("Should have panicked!") 
     } 
    }() 

    fmt.Println("Start Test") 
    panic("Mimic Panic") 
} 

Этот тест будет проходить при вызове функции, которая выходит с panic.

+0

Одно наблюдение: если у меня есть 10 тестовых ящиков, которые будут исполняться в последовательности, я не буду знать в начале, которая будет неудачной и которая пройдет. Обычно это может быть 8-й проход 2 неудачный/10-й проход 0 сбой/7-й проход 3 сбой, в зависимости от различные факторы, такие как сеть и т. д. В конечном итоге пользователь должен знать о тестовых проходах и проходах. – user1907849

+0

@ user1907849, то вы можете настроить 'defer func()' 'и' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' ', ' – VonC

+0

Но я не знаю, в чём все тестовые тестеры терпят неудачу, вот и проблема хардкора здесь .... иногда testcase1 может потерпеть неудачу, другие testcase10 могут потерпеть неудачу ... если иногда все тестовые файлы могут проходить ... – user1907849

Смежные вопросы