Testing categories/taxonomy: Unit, Integration and End-to-End Testing with Go

[Paul Michael Reilly]

It strikes me that when using the standard Go testing tools, Unit testing is writing tests for entities within a package.  There may be one or more unit tests for each file in a package.  There are many, many good examples of Go unit tests.

For an application or library (where an application generates a binary and a library is simply a package comprising sub-packages) integration testing consists of writing tests that include multiple packages.  This implies that an application with simply a main package can not have integration tests.  I cannot claim to have seen much in the way of Go integration testing.  Can someone suggest standard library packages that might provide examples of multiple packages being tested in unison?  It would seem that integration testing would leverage the standard Go testing and coverage tools.

End-to-end tests strike me as applying to one or more applications using tests written to drive and interact with the application binaries, either individually or in groups.  I've not seen much on this topic either and it strikes me that maybe benchmarks fall into this category.

It also strikes me that the 70/20/10 split between unit tests, integration tests and end-end tests recommended in a recent Google Test Automation Conference blog post is about right for large Go development projects.

Comments?

[Giulio Iotti]

On Saturday, December 19, 2015 at 4:40:14 PM UTC+2, Paul Michael Reilly wrote:

For an application or library (where an application generates a binary and a library is simply a package comprising sub-packages) integration testing consists of writing tests that include multiple packages.  This implies that an application with simply a main package can not have integration tests.  I cannot claim to have seen much in the way of Go integration testing.  Can someone suggest standard library packages that might provide examples of multiple packages being tested in unison?  It would seem that integration testing would leverage the standard Go testing and coverage tools.

Two dumb comments, with apologies if they really are too obvious:

1. For libraries, you can test their integration by using a testing package (a third package name like "package mylib_testing") so that you can only test exported members.

2. For a "package main", I suppose you can write different integration tests depending on what main does. From "expect" to test an interactive binary, to Selenium or equivalent for a webapp with front-end.

Sorry if I don't really add much to the conversation.

-- 

Giulio Iotti