Тестове и документация

23.10.2014

Въпроси за мъфини

Колко и какви начини има за обработване на грешки в Go?

Какъв трябва да е типа на върнатата грешка (според конвенцията)?

За какво се използва defer?

Къде използваме recover? Какво ще върне recover ако не сме се панирали?

Какви са основните разлики между паниките и изключенията?

Какво ще изведе следния код:

func f() {
  a := 5
  b := 10

  defer func(a int) {
    fmt.Println(a + b*2)
  }(b)

  b += a + 1
}

Disclamer

Днес няма да си говорим за acceptance testing, quality assurance или нещо, което се прави от "по-низшия" отдел във фирмата.

Всичко тук е дело на програмиста.

Митът

Проектът идва с готово, подробно задание.

Прави се дизайн.

С него работата се разбива на малки задачи.

Те се извършват последователно.

За всяка от тях пишете кода и приключвате.

Изискванията не се променят, нито се добавя нова функционалност.

Митът v2.0

Щом съм написал един код, значи ми остава единствено да го разцъкам - няколко print-а, малко пробване в main функцията и толкова.

Така или иначе няма да се променя.

А ако (не дай си боже) това се случи - аз съм го писал, знам го, няма как да допусна грешка.

Най-много да го поразцъкам още малко.

Тежката действителност

Заданията винаги се променят.

Често се налага един код да се преработва.

Писането на код е сложна задача - допускат се грешки.

Програмистите са хора - допускат грешки.

Промяната на модул в единия край на системата като нищо може да счупи модул в другия край на системата.

Идва по-добра идея за реализация на кода, по ред причини.

Искаме да автоматизираме нещата

За всичко съмнително ще пишем сценарий, който да "цъка".

Всеки сценарий ще изпълнява кода и ще прави няколко твърдения за резултатите.

Сценариите ще бъдат обединени в групи.

Пускате всички тестове с едно бутонче.

Резултатът е "Всичко мина успешно" или "Твърдения X, Y и Z в сценарии A, B и C се оказаха неверни".

Искаме да тестваме и производителността на нашия код.

Видове тестове

За какво ни помагат тестовете

За какво не служат тестовете

testing

Разбрахме се, че тестовете са ни супер важни.

Очевидно в стандартната библиотека на Go, има пакет за това.

За да тестваме foo.go, създаваме foo_test.go в същата директория, който тества foo.go

Ако тестваме пакета foo можем:

Или да ги смесваме.

Тестовете в `testing`

func TestFibonacciFastest(t *testing.T) {
    n := FibonacciFastest(0)
    if n != 1 {
        t.Error("FibonnaciFastest(0) returned" + n + ", we expected 1")
    }
}

Benchmark тестове

github.com/ChristianSiegert/go-testing-example

func BenchmarkFibonacciFastest(b *testing.B) {
    for i := 0; i < b.N; i++ {
        FibonacciFastest(40)
    }
}

Demo

Документиране на кода

go генерира автоматична документация на нашия код, вземайки под внимание: 

/*
    Example fobonacci numbers implementation
*/
package fibonacci

// Fastest Fibonacci Implementation
func FibonacciFastest(n uint64) uint64 {

// lookupTable stores computed results from FibonacciFast or FibonacciFastest.
var lookupTable = map[uint64]uint64{}

Виждане на документацията

На всички локално инсталирани пакети 

godoc -http=:6060

Документация на (почти) всички go пакети качени в BitBucket, GitHub, Launchpad и Google Project Hosting

godoc.org

Example тестове - шантавата част

Foo -> ExampleFoo
func ExampleHello() {
    Hello("hello")
    // Output:
    // hello
}

Въпроси?

fmi@golang.bg

http://fmi.golang.bg/

@fmi_golang