Why you should use Test::Class

最新推荐文章于 2021-07-23 11:00:33 发布

原创最新推荐文章于 2021-07-23 11:00:33 发布 · 393 阅读

CC 4.0 BY-SA版权

文章标签：

2 篇文章

订阅专栏

Test::Class attempts to provide simple xUnit testing that integrates simply with the standard perl *.t style of testing. In particular:

All the advantages of xUnit testing. You can easily create test fixtures and isolate tests. It provides a framework that should be familiar to people who have used other xUnit style test systems.
It is built with Test::Builder and should co-exist happily with all other Test::Builder based modules. This makes using test classes in *.t scripts, and refactoring normal tests into test classes, much simpler because:
- You do not have to learn a new set of new test APIs and can continue using ok(), like(), etc. from Test::More and friends.
- Skipping tests and todo tests are supported.
- You can have normal tests and Test::Class classes co-existing in the same *.t script. You don't have to re-write an entire script, but can use test classes as and when it proves useful.
You can easily package your tests as classes/modules, rather than *.t scripts. This simplifies reuse, documentation and distribution, encourages refactoring, and allows tests to be extended by inheritance.
You can have multiple setup/teardown methods. For example have one teardown method to clean up resources and another to check that class invariants still hold.
It can make running tests faster. Once you have refactored your *.t scripts into classes they can be easily run from a single script. This gains you the (often considerable) start up time that each separate *.t script takes.

If your *.t scripts are working fine then don't bother with Test::Class. For simple test suites it is almost certainly overkill. Don't start thinking about using Test::Class until issues like duplicate code in your test scripts start to annoy.
If you are distributing your code it is yet another module that the user has to have to run your tests (unless you distribute it with your test suite of course).
If you are used to the TestCase/Suite/Runner class structure used by JUnit and similar testing frameworks you may find Test::Unit more familiar (but try reading "HELP FOR CONFUSED JUNIT USERS" before you give up).