Motivation

When implementing tests for #279, I ran into a difficulty in that I needed my test program to import "time" package but not have any references to time.Time so that it would get DCEed. Normally, it's easy to do:

package main

import "time"

func main() {
    time.Sleep(time.Second)
}

However, when I tried to make it a test, that requires importing "testing" package. But the problem is that package already imports "time" and references time.Time internally, causing it not get DCEed.

Proposal

Let's move towards using a more flexible, low level testing system like is used in internal Go compiler tests (https://github.com/golang/go/tree/master/test folder) for compiler tests.

Using "testing" package is a very high level, large tool. It's great for package tests. But not if you want to test various compiler-level aspects. For example, you might want to test that something fails to compile, or causes a panic, etc.

Plan

If accepted, my implementation plan is to convert some of the existing Go compiler tests to run under GopherJS compiler. I was successful in getting 230~ passes and 40 fails. I can triage and skip the failing tests, and add the passing ones to GopherJS test suite.

That naturally paves the way to reuse that existing system for additional GopherJS specific compiler tests. That system has various actions like "rundircmpout", "compile", "compiledir", "build", "runoutput", "rundir", "errorcheck", "errorcheckdir", "errorcheckoutput", "run", "cmpout", "skip" which make it flexible and easy to add specific tests.

Closing Remarks

This is not a high priority and doesn't need to be done urgently, rather I propose we naturally move in this direction.