testing

Calling GitHub CI from a Wikimedia GitLab repo

by

I want to spend some more time developing a-wikimedia-cli (previosuly called mwcli), expanding what it can do, and adding integration tests for more of its functionality along the way. Having tests is useful, but having to wait for them every time you change something makes that slightly less appealing. Especially when your development system seems to be intense bursts of work and branches on the odd evening, or odd weekend, and not much development the rest of the time.

Some of the more involved tests create MediaWiki environments, start databases, install things, turn them off, turn them back on again and check that the CLI has done what it was supposed to. These have been running using Docker-in-Docker (or dind for short) on Wikimedia Cloud VPS machines for some time now, alongside the other checks and builds managed by Wikimedia GitLab. However the are only 2 small workers in the pool for the Docker-in-Docker tests, which are limited to 4 simultaneous jobs due to CPU and RAM constraints. not to mention it’s a waste leaving them on most of the time…

Meanwhile, the project also has a repository on GitHub which is mirrored to from GitLab, where GitHub Actions has machines quite capable of running these tests.

I have thought about moving entirely over to GitHub to solve this problem before, and have spun up forks there with CI before to make sure integration style tests pass before promoting them into branches in GitLab. However I never made a complete move. I have also dabbled with doing cross repo CI before for this setup, however it often ended in a disappointing mess.

However, maybe this time it will work *wink wink*…

Read more

A copy-paste go SQL mock for GORM

by

When it comes to writing robust and reliable tests for your Go applications, having a well-structured and efficient testing setup is crucial. One common challenge in testing Go applications is dealing with database interactions. To ensure that your code functions correctly, it’s essential to create a controlled environment for database operations during testing. In this blog post, we’ll explore how to create a mock GORM database for testing purposes, allowing you to isolate and verify your database interactions in a controlled manner.

Here is some copy-and-paste code (explained below) which should get you started.

import (
	"github.com/DATA-DOG/go-sqlmock"
	"gorm.io/gorm"
	"gorm.io/gorm/logger"
)

func NewMockGORM() (GORM *gorm.DB, close func()) {
	db, mock, err := sqlmock.New()
	if err != nil {
		panic(err)
	}

	// GORM always runs this query, so mock it for all tests
	mock.ExpectQuery("SELECT VERSION()").WillReturnRows(sqlmock.NewRows([]string{"version"}).AddRow("5.7.0"))

	GORM, err = gorm.Open(mysql.New(mysql.Config{Conn: db}), &gorm.Config{Logger: logger.Default.LogMode(logger.Silent)})
	if err != nil {
		panic(err)
	}

	return GORM, func() { db.Close() }
}Code language: PHP (php)

The code block above defines a NewMockGORM function that sets up a mock GORM database instance for testing. Let’s break down what this code does and how it can be a valuable addition to your testing toolkit.

Setting up a Mock GORM Database

Read more

Dependency injection in go using fx, and replacing services for test

by

I’m writing a new go application and ended up giving fx (by uber) a try for dependency injection. The getting started docs were brilliant for my use case (creating an API), but the examples for how to inject mock services for tests were lacking, so I decided to write some code examples of how I am currently using fx in tests.

General app setup

I set up my whole application in a app package, which pulls in all services that are needed.

Most of these are provided as constructor functions, with some more dynamic registration of routes as is done in the getting started docs.

package app

func New(additionalOpts ...fx.Option) *fx.App {
	return fx.New(
		fx.Provide(
			config.NewDefault,
			ses.NewSES,
			ses.NewEmailSender,
			mysql.NewGormGB,
			middleware.NewLimiterFactory,
			middleware.NewAuth,
			AsRoute(handlers.UserLogin),
			AsRoute(handlers.ListStuff),
			fx.Annotate(
				router.NewGinRouter,
				fx.ParamTags(`group:"routes"`),
			),
			server.NewHTTPServer,
		),
		fx.Invoke(func(*http.Server) {}),
		fx.Options(additionalOpts...),
	)
}Code language: Go (go)

Read more

MediaWiki CRAP – The worst of it

by

I don’t mean Mediawiki is crap! The Change Risk Anti-Patterns (CRAP) Index is calculated based on the cyclomatic complexity and code coverage of a unit of code. Complex code and untested code will have a higher CRAP index compared with simple well tested code. Over the last 2 years I have been tracking the CRAP index of some of Mediawikis more complex classes as reported by the automatic coverage reports, and this is a simple summary of what has been happening.

Read more