インポートコマンドは次のようになる。テーブルが既に存在するときインポート失敗するようになる。適当に試したところ、1つずつしかインポートできないようだった。ググり力が足りないのかもしれない。コマンドを見ればお分かりのとおり、フォーマットが決まっている。Kind名のところを随時変えてあげれば、まとめてシュッともっていける。次のようなスクリプトを書くと便利。いうものがあるのでそれを使うと良いらしい。2017の8日目の記事です。とある日、GAE/Goで書いたアプリのテストがなぜか途中で固まり、強制終了しないと戻ってこない現象に遭遇しました。今回の記事は、その調査と原因をまとめたものです。tl;drGoのテストはパッケージ毎に並列で動き、すべての終了を待機する。テストプロセスの子プロセスがpanicするとそのテストは終了を検知できない。テスト、一生おわらない!解決策はみつけられませんでした。Testインスタンスを使用したテストの最中にpanicすると起こります。Testインスタンスを使いまわしているときに起こります。Engineのローカル開発サーバ(google-cloud-sdk/platform/google_appengine/dev_appserver.py)を指します。aetest.NewInstance(nil)と書くと、内部でdev_appserver.pyが子プロセスとして起動します。調査テストが固まった後、試しにpsコマンドを打ってみると、dev_appserver.pyが生き残っていることに気付きました。このプロセスはTestMainで立ち上げたものですが、deferを使ってcloseするように書いているので、生き残ってしまっているのは不思議です。試しにdeferが呼ばれているかログを仕込んでみると、どうも呼ばれている気配がありません。testのソースコードを読んでみることにしました。TestMain現在Goの最新バージョンは1.9.2ですが、GAE/Goで使用されているバージョンは1.8.3なので、そちらのバージョンをみていきます。packageのM.Run()がTestMainの実行箇所です。...その中でrunTestsが呼ばれ、さらにt.Run()が呼ばれることで、各テストが実行されていきます。f)と書かれていて、テストメソッドが別のgoroutineで動いてることが分かります。...原因deferは、同一goroutineでpanicした場合は呼ばれますが、異なるgoroutineでpanicした場合に呼ばれません。#14542つまり、テストメソッド(Test_Foo)は、実はTestMainと異なるgoroutineで動いてた異なるgoroutine(Test_Foo)でpanicしてたため、TestMainのdeferは呼ばれなかった。終了処理が適切に実行されず、dev_appserver.pyが生き残ってしまっていたのでした。(dev_appserver.pyは、親プロセスがpanicでお亡くなりになったので、/sbin/launchdの養子になりました)つらい...。調査2TestMainのdeferが呼ばれない原因は分かりました。テストが固まる原因はまだ謎です。引き続き調べていると、次のようにテストを実行するとうまくいくことに気付きました。./...テストは、複数のパッケージを指定すると、CPUのコア数に応じて、パッケージ毎にパラレルに実行されます。1を指定することで、シリアルに実行できます。詳細は次のとおりです。available.シリアルに実行して動くということは、パラレルに実行するときの何かしらに問題が潜んでいそうです。testのソースコードをもう少し読んでみることにしました。testのソースコードはここにあります。ここで渡されているrunTestが開始地点のようです。{諸々と中身を見て、testStreamOutputがあやしいと目星をつけました。1))このフラグは、テストを実行したときの出力をバッファリングするかどうか決めるものです。os.Stderrに出力します。パラレル実行の場合、falseになりバッファリングします。}テストは次のような子プロセスで実行されます。-test.v=truerunTestは、この子プロセスを作るためにCmd.Startを実行します。その際、必要であれば子プロセスとつながるパイプを作ります。os.Stderrに出力する場合は、作りません。バッファリングする場合は、作ります。nil}子プロセスとつながるパイプを作ると、その読み取りと完了を待つようになります。Testインスタンス(dev_appserver.py)もfoo.testの子プロセスで動きパイプでつながります。その様子をpstreeやlsofを使って確認してみます。...0xfb6bae1f3bd0eeddと0xfb6bae1f3bd0ee1dでつながっていることがそれとなく分かります。dev_appserver.py)の終了を待機します。バッファリングが有効になると、パイプが閉じるまで待機します。前述のとおりテスト中にpanicして終了処理が実行されないと、dev_appserver.pyはいつまで経っても終わりません。testは待機し続けることになり、テストが固まってみえるようでした。一応、何の解決にもなりませんが、dev_appserver.pyをkillしてあげると、固まったテストが動きます。Testインスタンスの使い回しをやめると、手っ取り早く解決します。そもそもインスタンスの起動が遅いから使いまわしていたわけで、、😂Test_Caseで発生したpanicをうまいことTestMainまで伝搬してあげる仕組みがあると良いのかもしれません。テストが固まる現象を受け入れて、固まったときはpanicしてると想定する妥協もありなのかなーと思ってます。何か良い案あれば教えてください。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。