コア開発者のためです。標準ライブラリー外でこのパッケージを使用することは推奨されません。モジュールが入っています。テストスイートを実行するのに使います。始まるものは、特定のモジュールや機能に対するテストスイートです。モジュールを使って書くようにしてください。出力を比較する「従来の」テスト形式になっていますが、この形式のテストは廃止予定です。モジュールドキュメンテーション文字列に埋め込まれたテスト。モジュールを使ってテストを書く場合、幾つかのガイドラインに従うことが推奨されます。始め、テスト対象となるモジュール名で終えることです。始めて、そのメソッドが何をテストしているかという説明で終えます。これはテスト実行プログラムが、そのメソッドをテストメソッドとして認識するために必要です。テストメソッドにはドキュメンテーション文字列を入れるべきではありません。)を使用して、テストメソッドのドキュメントを記述してください。これは、ドキュメンテーション文字列が存在する場合はその内容が出力されてしまうため、どのテストを実行しているのかをいちいち表示したくないからです。いうコマンドラインインターフェースを通して起動したりできます。回帰テストの目的はコードを解き明かすことです。そのためには以下のいくつかのガイドラインに従ってください:テストスイートから、すべてのクラス、関数および定数を実行するべきです。これには外部に公開される外部APIだけでなく「プライベートな」コードも含みます。ホワイトボックス・テスト(対象のコードの詳細を元にテストを書くこと)を推奨します。ブラックボックス・テスト(公開されるインタフェース仕様だけをテストすること)は、すべての境界条件を確実にテストするには完全ではありません。すべての取りうる値を、無効値も含めてテストするようにしてください。そのようなテストを書くことで、全ての有効値が通るだけでなく、不適切な値が正しく処理されることも確認できます。コード内のできる限り多くのパスを網羅してください。分岐するように入力を調整したテストを書くことで、コードの多くのパスをたどることができます。テスト対象のコードにバグが発見された場合は、明示的にテスト追加するようにしてください。そのようなテストを追加することで、将来コードを変更した際にエラーが再発することを防止できます。テストがオペレーティングシステムの特定の状況に依存する場合、テスト開始時に条件を満たしているかを検証してください。インポートするモジュールをできるかぎり少なくし、可能な限り早期にインポートを行ってください。することで、テストの外部依存性を最小限にし、モジュールのインポートによる副作用から生じる変則的な動作を最小限にできます。できる限りテストコードを再利用するようにしましょう。時として、入力の違いだけを記述すれば良くなるくらい、テストコードを小さくすることができます。継承した全てのクラスがテストとして実行されることを忘れないでください。