Golangで使えそうなライブラリはあるだろうか？

こちらが見つかったが。。
https://github.com/flyingmutant/rapid

OpenAPIやgRPCやGraphQLとかのスキーマ定義に対して、汎用的にテストデータを作成できるか？

もし実装するとして、どういうI/Fにするか？

https://okiyama.dev/posts/2022-10-19-golang-package-testing-quick/

leanovate/gopter の方が有名っぽい

既存の(http|grpc|graphql) runnerのオプショナルなパラメータを追加して、特定のステップでプロパティベースドテストを実行できるようにする

APIチェーン的に引き継ぐべきパラメータとAPI仕様書のプロパティベースドで生成したパラメータをいい感じにmergeして実行できると良さそう。
使い勝手を考えると、通常通り指定されたパラメータの内、生成されたパラメータで上書きしないパラメータ名を指定できると良さそう？　🤔

vcrっぽい感じですね。

全く同じようなものにはなりませんが、
https://pkg.go.dev/github.com/k1LoW/runn#Capture に https://pkg.go.dev/github.com/k1LoW/runn/capture#Runbook を指定できるように runn run のオプションを拡張すると runn らしさがでるかもしれないと思いました。

永遠のベータは最近は流行らないですかねー？ 🤔
注目度が上がり、他のツール等の連携も増えてきているので、ちゃんとメジャーリリースした方が対外面では良さそうという判断でしょうか？
一つ確認しておきたいのですが、バージョンのナンバリングには意味を持たせますか（持たせたいですか）？
v1はLTSバージョンでv2は開発バージョン（比較的I/F変更が活発）とか。。
tagpr使っているので、２つのメインストリームを持たせるのは難しいかもと思っていますが。

考えられるトリガーは以下の感じですかね。

• Breaking Changeがある機能が反映されてから（反映してから）
• 初期構想の機能がおおよそ実装が出来た場合
• 新しい機能追加の方向性が決まった段階
• 周年（ファーストコミットからの経過日数？）
• 依存しているライブラリがメジャーバージョンアップした場合（Golangのバージョンも？）

注目度が上がり、他のツール等の連携も増えてきているので、ちゃんとメジャーリリースした方が対外面では良さそうという判断でしょうか？

はい。主に「オペレーションツールもしくはテスティングツールとして機能を枯らしたい」というのが理由です。
いつまでたってもBreaking Changeがガンガンあるようなツールだと使う側（runnの上に資産を積み上げる側）としては安心できないと思っています。
v1にしたあかつきには機能の追加はあっても挙動の変更はしないようにしたいと考えています。

バージョンのナンバリングには意味を持たせますか（持たせたいですか）？

はい。なの「でできるかぎりSemVer」を採用したいと思っています。
幸い、Goは後方互換性を保ちつつバージョンアップをしています。Goがv1の間は何も考える必要はないと思っています。runnもそのようにしたいと考えています。

とはいえ開発体制から考えてもLTSなどはサポートできないので、単純にSemVerで開発すればいいのではないかと思っています。

tagpr使っているので、２つのメインストリームを持たせるのは難しいかもと思っていますが。

これは必要になったらtagprに機能追加を提案すればいけそうだと考えています。

考えられるトリガーは以下の感じですかね。

良いと考えているのは「初期構想の機能がおおよそ実装が出来た場合」なんですけど、すでに私の想定を超えているので、どうしたもんかなーと。

まあ、「SemVerにする（v1にして挙動の変更はバージョンを上げる）」というだけなので記念的な何かでもいいとは思っています。

ちなみに、ガンガン開発した結果、v1がv100に到達してもそれは別に問題ないと思っています。なので開発に影響はないかなと...（たぶん気分の問題になりそう）

同一step内で結果確認する場合はcurrentを使っているか？とかですかねー

それも良さそうですね！

includeでのファイル名の大文字・小文字違いで環境依存でテスト失敗するケースがあるのでlintで気づきたいです。

includeでのファイル名の大文字・小文字違いで環境依存で

お、これはどう判定する（何を正しいとする）といいんですかねー

今のところ良いと思っているアイデアは「ステップへの defer: の導入です」
Go言語における defer ステートメントとほぼ同じ挙動をするイメージです。

メリット

• ステップの実行の途中で順々に後処理を追加できるという柔軟性がある
• ステップをそのまま後始末処理に回せるのでランブックのYAMLのネストが増えないし新しいセクションも増えない

デメリット

• defer の考え方が Gopher 以外にはわかりにくい（ defer: でなくてもいいのかも）
• step[*] 構文や current previous 構文と相性が悪い
  • しっかり検討してデザインをする必要がある

ステップへの defer: の導入です

runBookに対してdeferなのか？stepに対してdeferなのかによって結構I/Fが変わりそう
runBookだったら、後処理のイメージがつきやすい？

step[*] 構文や current previous 構文と相性が悪い

last という構文を用意して、どのstepまで処理されたのか？確認しながら

ステップの実行の途中で順々に後処理を追加できる

runBookでもincludeさせればそれほど制約にはならなさそう。

runBookに対してdeferなのか？stepに対してdeferなのかによって結構I/Fが変わりそう

ランブックに対してです。
ランブックをGoにおける関数ブロック、各ステップを関数ブロック内の処理だとイメージしてもらえると良いかと。

last という構文を用意して、どのstepまで処理されたのか？確認しながら

どちらかというと defer とマークされたstepは実行されずにランブックの終了まで待つイメージです。

次のようなランブックがあったとき

steps:
  -
    test: true
  -
    defer: true
    test: true
  -
    test: false

実行順は0->2->1になります。
かつ、2が失敗しても1はdeferとマークされているので実行されます。

そうすると、「step[*] 構文や current previous 構文と相性が悪い」というのがわかるかと思います。

具体的には3つめのstep（つまり2）で previous を使っていた場合、それは0にかかるのか1にかかってしまうのか。みたいな感じで悩ましいのです。

ステップの実行の途中で順々に後処理を追加できる

runBookでもincludeさせればそれほど制約にはならなさそう。

steps:
  -
    test: true
  -
    defer: true
    test: true
  -
    test: false
  -
    defer: true
    test: true
  -
    test: true

このとき、実行順は0->2->1です。

もし2が test: true なら 0->2->4->3->1 です。

このように段階的に後処理（1と3）を追加できるのが便利です。

goconでディスカッションした内容をベースに決めたいことをまとめました

どの論点を軸に優先させたいか？によって案の組み合わせはいくつかのパターンで表せるハズ。
パターンをABCでまとめて判断してみる。

私個人としては「runbook単位」のみかなあと思っています。
理由は「外部APIの実行に失敗したらDBの処理を戻す」「アップロードに失敗したら一時ファイルを削除する」など、後始末処理が複雑なユースケースがあるため、ステップ単位やランナー単位では対応できないと考えているためです。

クリーンアップ処理単位「runbook単位」より「1実行単位」が良い気がしています。

Include先で書いた defer はそのIncludeした側のrootランブックの実行終了時に実行されて欲しいことが多い...（今欲しいやつ）

各ランナーのValidatorというとHttpRunnerのOpenAPI Specと、gRPCRunnerのprotoがありますが、それとは別ということでしょうか？
runBookの構文チェック的にJSON Schemaを定義する感じでしょうか？
それとも、どこのyamlの一部分に対してJSON Schameを使って構文をチェック感じでしょうか？

構文のほうです！

個人的には、expr-langで全く困ってないのですが

同じく。

https://github.com/expr-lang/expr/blob/master/docs/language-definition.md#predicate

filter関係も結構使ってますが、こういうのもCommon Expression Languageであったりするんですかね？

全く同じ機能というのはないと思います。
https://codelabs.developers.google.com/codelabs/cel-go#7 な感じで拡張が必要そうです。

ステップ毎にかかった時間を計測したい

profileで取得できますね。逆にいうと実行時間はprofileをonにするのと同じことになります。

needsセクションを作ることができたら、いわゆる前処理の書き方に選択肢が生まれる

凄い未来を感じます。
妄想ですが、複数シナリオ実行時に

1. needsで指定されたシナリオが既に実行済みの場合はその結果を踏まえて処理する
2. needsで指定されたシナリオが未実行の場合は、ランブック実行前にシナリオ実行される

となったら、処理時間の短縮にも繋がりそう。
bind変数を保持し続けないといけないのでメモリが凄いことになりそうですが 😅

妄想ですが、複数シナリオ実行時に

求める挙動が完全に同じです！

処理時間の短縮にも繋がりそう。

まさにこれがしたい感じですね。

bind変数を保持し続けないといけないので

現状、実行後にstoreの値は消していないんですよね。

https://github.com/k1LoW/runn/blob/b607f602729f286fd8f747c4bb76fd2e790c2f49/operator.go#L115-L118 で実行後に値を取れたりするので。

なのでメモリ使用量は変わらない可能性があります（調整もしないとな）。

無事実装しました
https://github.com/k1LoW/runn/pull/991

なるほど！すっきり理解できたかもです。

frontend -> backend な構成において

1. runn -> backend でシナリオテストを実行する

• この時runnはリクエストとレスポンスを何かしらの形でファイル等に書き出しておく（仮に「カセット」とする）

2. runn（もしくは別のなにか）はカセットを使ってモックサーバとして起動する
3. frontend -> runnモックサーバでテストが実行できる

こんなイメージでしょうか？

ですですー。
カセットという用語は良さそうですね。
VCRを連想させますね。
VCRのカセットと同様の挙動でいいのか？シナリオならではの+αがあるのか？は議論はほしそうですねー
カセットがAPIとの通信のキャプチャ＆リプレイさせる為だけの情報にするか？
カセットの情報にシナリオの可変値を識別して埋め込んでおくか？

varsを可変値として柔軟なMockサーバーになりそう（実装は大変そうですが 😅

個人的にはrunnとモックサーバとの間に共通のフォーマット（カセット的なもの）を作る（もしくは既存のものがあればそれに乗っかる）のが良いかなあと思います。

その共通フォーマットにプログラマブルな要素を含めるのか、それとも、そのカセットをいい感じにいじる機能をモックサーバ側に作る　かなあと思っています。

なので

カセットの情報にシナリオの可変値を識別して埋め込んでおくか？

上記ではない感じです。runnのランブックとは切り離したフォーマットで良いかなと（当然近いフォーマットでもいいわけですが）。

まあ実現できそうなのはHTTPランナーとgRPCランナーのシナリオだけですね。

今ならGithub ReadyなMermaid形式がいいんですかね？
tblsでERD出す時に使っていませんでしたっけ？

Mermaidもいいと思いますー DOTまでならテキスト出力ですし PlantUML も依存が書けるならありかもです。

あとは「依存グラフ」の先にある機能を想像しながらのコマンドの設計ですかねえ。

コマンド名も悩む

こちら想定しているユースケースとしてはどんな感じでしょうか？

• 2回実行されることを防ぎたい？
• セキュリティ的な観点？

具体的なイメージがあるとインターフェースも決めやすいかと考えています。

依存グラフをシンプルにするためですね。
そのランブックが意図せずinclude/needsされてしまうのを防ぐイメージです。

runn.Capturerインターフェースの現状整理

各種runnerが実行時の状態をキャプチャーする為のインターフェースが定義されている

https://github.com/k1LoW/runn/blob/main/capturer.go#L10-L49

このインターフェースを通して

• cmdout.go
• debugger.go
• capture/runbook.go

これらのキャプチャーする機能を実装して以下の機能を実現している

• ステップ毎の実行結果やエラーのキャプチャしてstoreへの格納や、verbose出力
• 各種runnerの実行結果をキャプチャーしてデバック出力

現状のインターフェースの課題

• ログやデバック観点でキャプチャしたいイベントと、最終結果を格納したいタイミングが異なる
  ※今回はデバック出力文脈でイベントを増やそうとしている
  デバック文脈では、最終結果がFix。。ステップが完了する前の状態を扱ったりする
• runnerが増えて新しいキャプチャ内容が増えると、拡張ポイントが増えすぎる？
  確定結果を扱うインターフェースと、途中結果を扱うインターフェースが混ざっているかもしれない。（今回のexecの標準出力は1行毎にインベント通知したさがあるが、現状では全ての出力結果を一つの文字列として扱っている）
• インターフェース定義されている関数によっては、例えばstoreの格納文脈等では実装しづらいものがある

Execのログに関していうと
https://github.com/k1LoW/runn/issues/986 とも関係するかなあと思っています

CaptureExec* だけストリーム（io.Writer）が欲しくなっていませんか？（私はそうです）

いただいだ「現状のインターフェースの課題」をみると、もう少し広く考える必要がありそうな気もしますね。。。

CaptureExec* だけストリーム（io.Writer）が欲しくなっていませんか？（私はそうです）

CaptureSSH* もですねー
runner側はStdoutPipeとかでストリーム処理する感じになってしますしね。
ストレームベースにするか？テキストベースで１行づつ処理する感じにするか？どうかはまだ悩んでいます。
 storeにstdoutやstderrを格納する際に、既存のCaptureExecStdoutとCaptureExecStderrを残すのか？
それとも既存のインターフェースを廃止して新しくストリーム処理させる function  側でstoreに格納させるのが良いか？が関わってくると考えています。
それによってテキストベースで処理させるインターフェースの方が望ましいのか？が決まってくると考えています。

storeにstdoutやstderrを格納する際に、既存のCaptureExecStdoutとCaptureExecStderrを残すのか？

なるほど...うおおどうすればいいんだ....

storeにstdoutやstderrを格納する際に、既存のCaptureExecStdoutとCaptureExecStderrを残すのか？

一旦、残した状態で実装を進めてみました。

もう一点課題が出てきました。

標準出力と標準エラー出力のハンドリングを独立して非同期化するか？という課題が発生しました。
出力内容が混ざってしまう（それに伴うテストがFlaky化する）問題が出てきました。
これはdebug時を考慮して標準出力→標準エラー出力で逐次処理の方が、良さそうでしょうか？

正常な出力と考えると混ざるべきだと思っています。

うーんまだ行ごとに出力するようなメソッドを作成する方針に振れない自分がいます。

なるほどー
混ぜるとテストしづらさが出てしまうので悩ましいですね

うーんまだ行ごとに出力するようなメソッドを作成する方針に振れない自分がいます。

インターフェースを変更せずにexec runnerにTeeオプションを追加して
オプションが有効になっている場合にのみTeeReaderを挟む様にして標準出力するようにするにはどうでしょうか？

https://github.com/k1LoW/runn/pull/1056/files#diff-5dbc24f000f25dbb39d02206d7efaac855fe1766eb4970b721f6ac18efdb1cc7R110

debugとの責務とは独立したオプションというイメージです。

exec runnerのみを拡張するというのはミニマムで良いかもですね（オプション名、 tee 以外にいい感じのないですかねー）。これ賛成です。

とはいえ、debugよりもexec runnerのオプションのほうが情報量が多いのはアレですね。

なんとかしたい...ウルトラCがあればいいんですけど。

混ぜるとテストしづらさ

「STDINとSTDOUTの情報量全てが出力されているか」とかで良さそうに思いました。本来コマンドの出力をstreamにしている状態ではSTDINとSTDOUTが混ざっていますし。

今回実現したい機能の特性を考えるとそのほうが自然に思いました。

tee（？）オプションはあくまで「ストリームで出力を見たい」だけという立ち位置で良さそうです。

オプション名、 tee 以外にいい感じのないですかねー

liveoutput ではどうでしょうか？

tee（？）オプションはあくまで「ストリームで出力を見たい」だけという立ち位置で良さそうです。

大分シンプルになりました:+1:

最高です！！！！！！！！！！！！！名前もめちゃいい！！！！！！個人的に気に入りました。

1点だけ、
英語+YAML的には liveOutput になると思うのですがどうしましょう？

Merged