Extensibility docs should signpost & warn where developers could be caught out by cross-process marshalling
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 45/100
- issue の種類
- ドキュメント
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
調査の方向性
まず ITestBuilder のドキュメントと、検出およびテスト実行のフェーズを見つけます。拡張ポイントに関するガイダンスをどこに記載すべきか確認し、その後、プロセス間のマーシャリング境界を文書化し、検出中に作成された値やイベントサブスクリプションは、実行中に同じオブジェクトを参照するとは限らないことを警告します。
索引モデルが issue の本文から書いたものです。
説明
This relates to something that I have had this explained to me somewhere before, but it was years ago and I can't find where that discussion happened. I've looked through SO questions and issues/discussions on the NUnit repo.
There is a limitation, really a feature/consequence of NUnit's design (and not one I consider to be bad) In the default usage the "discovery and test suite/case creation" phase occurs at arms length to the "test execution" phase, I believe in a separate .NET process. From what I recall of the last time this was explained to me, objects/values which are created during discovery/creation are then marshalled in some manner over to the execution. Examples of this are where test case parameter values are injected by something which implements ITestBuilder.
When those objects turn up in the test case as a method parameters, they are not actually the precise same objects as were created in the test builder, because they have crossed a boundary (again, I think that's a process boundary). This can have some unexpected and baffling consequences to a developer if they had not had this boundary-crossing pointed out to them. For example, an object which emits events passed as a test case parameter. If an event listener is subscribed to that object over in the "discovery & creation" part of the test suite then events which are emitted during the test (triggered by logic that executes within the test) won't be observed by the subscriber. That's because the object emitting the events isn't actually the precise same object that was subscribed-to. The object emitting the events is a marshalled-copy of the original object.
I think the docs should point this out for extension points which can lead to this behaviour. It's not obvious if you are not already familiar with the deep internals of NUnit. Even having already been told once, over the course of a few years I managed to forget and was caught out by this a second time.
- 主要言語
- Dockerfile
- スター
- 601
- フォーク
- 158
- 平均マージ
- 15時間 46分
- マージ済み PR（30日）
- 23
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
nunit/docs のほかの issue
-
type:newpage
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
area:framework
難易度 4/5 3〜5日 初心者へのやさしさ 40/100
メンテナーはふだん 1 日以内に返信
-
Document F# EqualToオープンarea:framework
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
-
area:framework
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
add-on doc enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
JuliaGraphics/ColorTypes.jl#344 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
agent-butler-finding chore
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
jordansmall/spindrift#4146 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
DaveGamble/cJSON#1093 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
midnightntwrk/midnight-docs#1430 ·
メンテナーはふだん 1 日以内に返信
-
bug documentation needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
stacklok/docs-website#1185 ·
メンテナーはふだん 1 日以内に返信