2017-05-06 11 views
1

私はGikngoを使用してappengineのテストを書こうとしています。Gikngoテストはgoappテスト中にハングする

次のようにテストのための私のセットアップは次のとおりです。

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. 
    }) 
}) 

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

これは、APIサーバーがアクセス不能になったことを示しているようです。しかし、テスト出力はこれを示していないようです。

goappテストをデバッグする方法は何ですか?

答えて

0

イチョウやゴランはこれと関係がないことが判明しました。 dev_appserver.pyから1秒間に読み取れるフィールドの数にはいくつかの制限があるようです。 (dev_appserverが内部的に使用するDBであるSQLiteに関連している可能性があります)。

次のコードは、問題を指摘する:

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() 
    } 
} 

240個の操作の制限を回避する方法を考え出す上の任意の助けをいただければ幸いです。私が考えることのできる技術の1つは、人為的に遅延を注入することです。

関連する問題