Different, more readable, table driven testing approach

[Silthus]

Hey,

first off awesome work with the guide to learn go by using TDD. I love it ❤️

I wanted to suggest an alternative approach to table driven tests, which in my opinion is more readable and less clutter in the code. This refers to the Structs, methods & interfaces chapter.

At the end you introduce table driven testing and suggest to use a name variable in the struct to make the test more readable. I want to suggest the following alternative:

func TestArea(t *testing.T) {
	assertArea(t, Rectangle{10.0, 10.0}, 100.0)
	assertArea(t, Circle{10.0}, 314.1592653589793)
	assertArea(t, Triangle{12.0, 6.0}, 36.0)
}

func assertArea(t *testing.T, shape Shape, expected float64) {
        t.Helper()
	t.Run(reflect.TypeOf(shape).Name(), func(t *testing.T) {
                t.Helper()
		got := shape.Area()
	        if got != expected {
		        t.Errorf("%#v got %g want %g", shape, got, expected)
	        }
	})
}

This can of course be tranfered to any other use-case where you would use table driven testing. I think it is a lot more readable and cleaner compared to the original:

func TestArea(t *testing.T) {
	areaTests := []struct {
		name    string
		shape   Shape
		hasArea float64
	}{
		{name: "Rectangle", shape: Rectangle{Width: 12, Height: 6}, hasArea: 72.0},
		{name: "Circle", shape: Circle{Radius: 10}, hasArea: 314.1592653589793},
		{name: "Triangle", shape: Triangle{Base: 12, Height: 6}, hasArea: 36.0},
	}

	for _, tt := range areaTests {
		// using tt.name from the case to use it as the `t.Run` test name
		t.Run(tt.name, func(t *testing.T) {
			got := tt.shape.Area()
			if got != tt.hasArea {
				t.Errorf("%#v got %g want %g", tt.shape, got, tt.hasArea)
			}
		})
	}
}

What do you think about this approach? Maybe worth mentioning in the docs?

[quii]

Hey

Sorry for the late reply, I don't seem to get notifications on discussions.

There's a few trade-offs to consider here. You could comfortably argue your top version is a little simpler to read but it's not as ergonomic in terms of running tests. If you wish to run an individual test, with table tests you can. With your approach you cannot.

I'm happy with the table version because for all practical uses, I don't read the for-loop bit, I just expect the table to "describe the truth".