银杏测试在goapp测试期间挂起

Question

I'm trying to use Gikngo to write some tests for appengine.

My setup for the tests is as follows:

suite_test.go:

BeforeSuite() {
  inst, err = aetest.NewInstance(options)
  if err != nil {
    Fail(fmt.Sprintf("%s", err))
  }
}

var(
  req *http.Request
  ctx context.Context
)
BeforeEach() {
  req = inst.NewRequest()
  ctx = appengine.NewContext(req)

  // Clean up local datastore using the context.
}

validation_test.go

Describe("Some Test", func() {
  It("ValidateFoo", func() {
    // Access ctx here
  })
  ...
  It("ValidateBar", func() {
    // Access ctx here.
  })
})

I see our tests consistently hanging with the error of the type:

Expected success, but got an error:
    <*url.Error | 0xc8210570b0>: {
        Op: "Post",
        URL: "http://localhost:59072",
        Err: {s: "EOF"},
    }
    Post http://localhost:59072: EOF

This seems to indicate that the API server has become inaccessible. However, the test output does not seem to indicate this.

What are the ways in which we can debug a goapp test?

Answer 1

It turns out that Ginkgo or Golang had nothing to do with this. There seems to be some limitation on the number of fields one can read per second from dev_appserver.py. (I suspect that it might be related to SQLite which is the DB that dev_appserver uses internally).

The following code points out the problem:

package preorder

import (
    "fmt"
    "testing"

    "google.golang.org/appengine"
    "google.golang.org/appengine/aetest"
    "google.golang.org/appengine/datastore"
)

func TestLoad(t *testing.T) {
    opts := aetest.Options{StronglyConsistentDatastore: true}
    inst, _ := aetest.NewInstance(&opts)
    defer inst.Close()

    for i := 0; i < 10000; i++ {
        req, _ := inst.NewRequest("GET", "/", nil)
        ctx := appengine.NewContext(req)

        k := datastore.NewKey(ctx, ENTITY_NAME, "", 12345, nil)
        var entity Entity
        datastore.Get(ctx, k, &entity)
        fmt.Println("Iteration Count: ", i)
        ctx.Done()
    }
}

Any help on figuring out how to work around the limit of 240 operations would be appreciated. One technique I can think of is to artificially inject delays.