SelectNodes()
で呼び出されてXmlDocument
nullを返すことは可能ですか?
私の苦境は、100%の単体テストコードカバレッジに到達しようとしていることです。ReSharperは、メソッドからのnullの戻りを防ぐ必要があると言っていますSelectNodes()
が、XmlDocumentがnullを返す方法がわかりません(したがって、guard句をテストして100%の単体テストカバレッジに到達する方法がありません!)
SelectNodes()
で呼び出されてXmlDocument
nullを返すことは可能ですか?
私の苦境は、100%の単体テストコードカバレッジに到達しようとしていることです。ReSharperは、メソッドからのnullの戻りを防ぐ必要があると言っていますSelectNodes()
が、XmlDocumentがnullを返す方法がわかりません(したがって、guard句をテストして100%の単体テストカバレッジに到達する方法がありません!)
Reflectorを見ると、XmlDocumentの基本クラスであるXmlNodeのSelectNodes()メソッドは、ナビゲーターを作成しようとしてnullを返した場合にnullを返す可能性があります。CreateNavigator()は非常に複雑で、いくつかの状況では実際にnullを返します。これらの状況は、不正な形式のXMLドキュメントに関連しているように見えます。したがって、SelectNodes()の失敗のテストケースがあります。
XmlDocument 自体で SelectNodes を呼び出していて、それが実際には XmlDocument であり、派生クラスではない場合、SelectNodes は null を返しません。
子孫クラスを作成して CreateNavigator(XmlNode) メソッドをオーバーライドすると、SelectNodes が null を返す可能性があります。
同様に、EntityReference、DocumentType、または XmlDeclaration ノードで SelectNodes を呼び出すと、同様に null が返されます。
つまり、作成したばかりではない XmlDocument または XmlNode を 100% カバーするには、null をテストする必要があります。
100%のコードカバレッジに到達する必要がありますか?確かに、それは通常の(すなわち、制御可能で、テスト可能な)状況下でも可能ですか?
ブロックのような「シンタックスシュガー」構造を使用すると、何らかの環境条件(ソケットの破損やディスクの破損など)が発生しない限り実行できないusing {}
「隠された」コードパス(ほとんどのfinally {}
場合、またはブロック)が作成されることがよくあります。catch {}
仕方。