tinygo test command - step 1

[carolynvs]

I would like to implement tinygo test. Not a full implementation of go test but enough to get us started and build from there. My goal is to get enough working so that we can use it to test tinygo itself.

• tinygo test would accept no arguments at first, local directory mode. (for example specifying a list of packages to test or a run filter, or verbose flag would come in later PRs).
• It looks for all *_test.go files in the current directory.
• Identifies functions in those files that matches func TestXxx(*testing.T) where Xxxx starts with an uppercase letter.
• The testing library is something that I may need more guidance on as I dive in further. I'm not 100% clear on what I can use from the stdlib and what will need to be reimplemented yet. If it needs reimplementing, testing.T will start off as an empty/placeholder struct.

Would this be a welcome contribution?

My style is to submit WIP PRs, and get enough in that it's useful without trying to push through a monolithic PR that does everything. So if y'all are okay with this, I'd implement it, get it merged, and then work on improving it beyond what is outlined here (for example supporting more flags) in additional pull requests. Let me know if you have other preferences.

[aykevl]

tinygo test would be very useful to have!

This change is probably an AST-only change, in that most changes will be in the loader subpackage and not in the compiler.

My understanding of go test is that it does the following:

• It adds the test build tag. This is how _test.go files are included.
• It transforms the AST to run the tests instead of main.

You may find more information in this package:
https://github.com/golang/tools/tree/release-branch.go1.11/go/loader
TinyGo used this package in the past but switched to a custom loader to have good CGo support.

You can do the change however you like, but incremental changes are much easier to review so what you describe (a WIP branch) sounds good.

As for a MVP, I think being able to test the errors package would be a good starting point. It is probably the smallest package in the stdlib and doesn't depend on anything (in go1.11, it is being changed now).

There is a possibility that the testing package does not yet compile, but you'll likely notice that soon enough.

[carolynvs]

Thanks for the pointer to the loader, that is exactly what I was looking for!

[deadprogram]

I would like to write tests for the various subpackages in https://github.com/tinygo-org/drivers

To do that, I need a way to resolve the machine package references. For example, if I want to have a mock of the machine.I2C interface so I can write a test something like this:

func TestBMP180Driver(t *testing.T) {
        i2cTester := NewI2CTestInterface()
        i2cTester.SetTxImpl = func(addr uint16, w, r []byte) error {
                r[0] = bmp180.CHIP_ID
		return nil
	}
	sensor := bmp180.New(i2cTester)

	connected := sensor.Connected()
        if !connected {
               t.Fail()
        }
}

In the above bmp180.New() is defined eher https://github.com/tinygo-org/drivers/blob/master/bmp180/bmp180.go#L44 as:

func New(bus machine.I2C) Device {...}

Any thoughts on this? Or is it too complex for this initial start to being able to run a tinygo test command at all?

[aykevl]

I would start with a bare-bones tinygo test command that does nothing special, just to have something working.

When that is working, perhaps it is easiest to repurpose the existing dummy I2C implementation in the machine package as a testing system, or make it possible to override the existing no-op behavior with an actual implementation (which may be used for testing). The advantage is that it requires nothing special from the test subcommand. In fact, that may already be possible right now by simply using the standard Go compiler for testing and importing the machine package as github.com/tinygo-org/tinygo/src/machine.

[deadprogram]

Now that the initial implementation of tinygo test has been merged into dev branch I am going to close this issue. Let's open new individual issues as the feature continues to evolve.

Thank you very much @carolynvs for all of your work on this so far!