Голанг не может проверить в той же упаковке

Возникла проблема при создании модульного теста одного из моих исходных файлов ( commonutil.go)

package util

import "github.com/nu7hatch/gouuid"

// GenerateUUID Returns generated UUID sequence
func GenerateUniqueID(hostname string) (string, error) {
    var result, err = uuid.NewV4()
    return hostname + ":" + result.String(), err
}

Для вышеупомянутого источника я создал тестовый файл "commonutil_test.go" (в том же пакете)

package util

import "testing" 
func TestCommonUtil(t *testing.T) {
t.Run("Test generate UUID", func(t *testing.T) {

    var uuid, _ = GenerateUniqueID ("test")
    //fmt.Printf("UUID isa %v \n", uuid)
    if uuid == "" {
        t.Errorf("UUID expected, but result is empty ")
    }
})

Однако при попытке выполнить "go test util/commonutil_test.go" он показывает:

util \ commonutil_test.go: 8: undefined: GenerateUniqueID
FAIL аргументы командной строки [сборка не удалась]

Изменение на util.GenerateUniqueID в тесте решит проблему, однако при запуске покрытия с использованием Goconvey возникнет сбой сборки:

Не удается загрузить пакет: цикл импорта не разрешен. rudygunawan.com/MyProject/HFLC-Go/util импортирует rudygunawan.com/MyProject/HFLC-Go/util

Есть идеи, чтобы решить эту проблему? Я сбит с толку.

Go версия Go1.7.1 Windows/386

Источник

3 ответа

Решение

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

Источник

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

Я хотел этого, поскольку это была своего рода разработка, основанная на тестах, когда я хотел запускать тесты только для кода, над которым я работал в данный момент, а не для всех тестов, выполняемых за x минут.

Решение оказалось не запускать тесты из файла, а запускать определенный тест по имени (на самом деле регулярное выражение). Итак, в вашем случае, я думаю, это будет:

      go test ./util -run TestCommonUtil

Альтернатива, кажется, перечисляет все файлы, необходимые для сборки вашего тестового кода:

      go test util/commonutil_test.go util/commonutil.go
Источник

Я обычно пишу модульные тесты Go, чтобы иметь один (или более) ..._test.go файлы, в том же пакете, что и тестируемый код, с одним Test... функция для каждого широкого набора тестов.

package util

import "testing

func TestGenerateUniqueID(t *testing.T) {
   var uuid1, uuid2 string
   uuid1, err = GenerateUniqueID("test")
   if err != nil {
     t.Errorf("Expected no error, got %s", err) // Maybe Fatalf?
   }
   if uuid1 == "" {
     t.Errorf("Expected non-empty string, got empty string (uuid1)")
   }
   uuid2, err = GenerateUniqueID("test")
   if err != nil {
     t.Errorf("Expected no error, got %s", err) // Maybe Fatalf?
   }
   if uuid2 == "" {
     t.Errorf("Expected non-empty string, got empty string (uuid2)")
   }
   if uuid1 == uuid2 {
     t.Errorf("Expected uuid1 and uuid2 to be different, both are %s", uuid1)
   }
}

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

Источник
Другие вопросы по тегам