As you plan the development of your application, consider how the core concerns could be separated to maintain flexibility. The following suggested structure should provide some inspiration:
| project/ | The root of the project structure. This package should define the interfaces and utility functions used by the rest of the project. These files should not depend on any sub-packages. |
| project/logic/ | This package will contain most of your application logic. Careful consideration should be given to which functions and types are exposed, as they will form the API that the rest of your application will depend upon. There may be multiple packages that contain application logic as you separate the application's concerns. An alternative, domain-specific term may be preferred to logic. |
| project/storage/ | Most applications will rely upon a data source of some kind. This package will define one or many possible data sources. They will conform to an interface in the top-level project so that data access can be passed between packages of the project. |
| project/gui/ | This package is the only place where your graphical toolkit should be imported. It is responsible for loading your application GUI and responding to user events. It will probably access data provided by a storage package set from the application runner. |
| project/cmd/appname/ | The Go convention for application binaries is that they reside within a cmd/appname sub-package. The actual package for this directory will be main, and it will contain, minimal code that is required to load and run the main application defined within the other packages. It will probably initialize a storage system, load the application logic, and instruct the graphical interface to load. |
When writing tests in each of these packages, they will focus on the functionality of the current package. The logic package should have very high unit-test coverage, whereas the storage package may rely more on integration testing (for a refresher on the different types of testing see www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing). The gui package, which is often considered the hardest to test, could directly import the logic package in its tests, but should probably not include the main storage package to validate its functionality. You can read more about the recommended package structure at medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1.
Following a sensible structure will aid significantly in making your application testable, as many developers are probably already aware. It is often much harder, however, to test the graphical portions of an application. Designing your application to be unit-testable from the beginning will often result in a code base that is better organized and will naturally lead to code that is easier to understand and change. Let's take a look at what Test-driven Development (TDD) can teach us about building graphical interfaces.