Why you should use Test::Class
2009-11-12 00:30
477 查看
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.
Why you should not use Test::Class
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).
相关文章推荐
- 10 Reasons Why You Should Use AngularJS(中文翻译)
- Kill -9 Why You Should Not Use It Unless Absolutely Necessary
- Why you should use async tasks in .NET 4.5 and Entity Framework 6
- Why You Should Use Unicode 为何要使用Unicode
- [导入][链接]Five reasons why you should never use PostgreSQL
- Why you should use Umbrello UML Modeller
- Why you should always use PHP interfaces
- Why you should use talloc for your next project
- When should you use a class vs a struct in C++?
- Log4j---Why You Should Use “isDebugEnabled” ?
- Your Podfile has had smart quotes sanitised. To avoid issues in the future, you should not use TextE
- Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test java.lang.IllegalStateException
- Why you should embrace functional programming in Java 8
- Part 57 to 58 Why should you override ToString and Equal Method
- Why you should take your 20s seriously
- Can't use 'defined(@array)' (Maybe you should just omit the defined()?)(编译内核时候的错误)
- the "find" which you should kown that how to use it
- NBA Superstar Chris Bosh: Here’s Why You Should Learn to Code
- Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at kernel/timeconst.pl
- Android Libraries You Should Use in Every Project