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

22.10.2013

Disclamer

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

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

Митът

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

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

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

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

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

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

Митът v2.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Unit tests - проверяват дали дадено парче код/пакет работи правилно в изолация
Integration tests - проверяват дали няколко модула си общуват правилно
Functional tests - проверяват дали крайната функционалност е както се очаква
Benchmark tests - извикват една и съща операция n пъти и записват времето, отнело за изпълнение

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

Откриват грешки по-рано
Позволяват ни уверено да правим промени в системата
Дават сигурност на клиенти, шефове и програмисти
Представляват пример как се работи с кода
Помагат разделянето на интерфейс от имплементация
Служат като документация и спецификация
Посочват ни слабите от към производителност части

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

Не доказват, че приложението работи
Не доказват, че приложението е с достатъчно добра производителност
Не са Quality Assurance

testing

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

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

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

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

Дефинират се като функции, които приемат указател към testing.T
Функциите трябва да започват с Test и слеващата буква да е главна
Един тест минава успешно, ако не се изпълни t.Error(), t.Fail(), t.Fatal()...

Benchmark тестове

Дефинират се като функции, които приемат указател към testing.B
Функциите трябва да започват с Benchmark и слеващата буква да е главна
Тя се състои от for цикъл, извикващ t.N пъти тестваната функция
go е достатъчно умен да реши колко пъти да я извика, за да получи адекватни резултати
Стъпките са 1, 100, 10,000, 1,000,000 50,000,000.

github.com/ChristianSiegert/go-testing-example

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

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

всеки коментар, в началото на файл
всеки коментар, дефиниран над функция, метод, тип
всеки коментар до име в тип, var, const

godoc -http=:6060

Example тестове

Тук вече нещата стават шантави.

Функцията започва с Example, последвана от типа (ErrorFoo)
Ако искаме да тестваме метод го слагаме с подчертавка след типа (ErrorFoo_Bar)
Пишем няколко реда, в които използваме нашия тип
Завършваме с коментар от изхода, започващ с Output:
Ако изходът от кода не съвпада с коментара, тестът фейлва