Ports 搜索

Term::UI is a transparent way of eliminating the overhead of having to format a question and then validate the reply, informing the user if the answer was not proper and re-issuing the question. Simply give it the question you want to ask, optionally with choices the user can pick from and a default and Term::UI will DWYM. For asking a yes or no question, there's even a shortcut.

Term::Visual is a "visual" terminal interface for curses applications. It provides the split-screen interface you may have seen in console based IRC and MUD clients. Term::Visual uses the POE networking and multitasking framework to support concurrent input from network sockets and the console, multiple timers, and more.

An xUnit style testing framework inspired by Test::Class and built using Moose. It can do all the important things Test::Class can do and more. The prime advantages of using this module instead of Test::Class are flexibility and power. Namely, Moose. This module was created for a few of reasons: To address perceived limitations in, and downfalls of, Test::Class. To leverage existing Moose expertise for testing. To bring Moose to the Perl testing game.

Aggregate perl test for better performance

Test::Assertions provides a convenient set of tools for constructing tests, such as unit tests or run-time assertion checks (like C's ASSERT macro). Unlike some of the Test:: modules available on CPAN, Test::Assertions is not limited to unit test scripts; for example it can be used to check output is as expected within a benchmarking script. When it is used for unit tests, it generates output in the standard form for CPAN unit testing (under Test::Harness).

UUID - Perl extension for using UUID interfaces as defined in e2fsprogs.

Testing is usually the ugly part of Perl module authoring. Perl gives you a standard way to run tests with Test::Harness, and basic testing primitives with Test::More. After that you are pretty much on your own to develop a testing framework and philosophy. Test::More encourages you to make your own framework by subclassing Test::Builder, but that is not trivial. Test::Base gives you a way to write your own test framework base class that *is* trivial.

Sometimes you want to make sure that your "faster" algorithm really is faster than the old way. This lets you check. It might also be useful to check that your super whizzo XS or Inline::C version is actually faster. This module is based on the standard Benchmark module. If you have lots of timings to compare and you don't want to keep running the same benchmarks all the time, you can pass in a result object from Benchmark::timethis() instead of sub routine reference.

This perhaps ridiculous-seeming module was created to test routines that manipulate random numbers by providing a known output from rand. Given a list of seeds with srand, it will return each in turn. After seeded random numbers are exhausted, it will always return 0. Seed numbers must be of a form that meets the expected output from rand as called with no arguments -- i.e. they must be between 0 (inclusive) and 1 (exclusive). In order to facilitate generating and testing a nearly-one number, this module exports the function oneish, which returns a number just fractionally less than one. Depending on how this module is called with use, it will export rand to a specified package (e.g. a class being tested) effectively overriding and intercepting calls in that package to the built-in rand. It can also override rand in the current package or even globally. In all of these cases, it also exports srand and oneish to the current package in order to control the output of rand. Alternatively, this module can be used to generate objects, with each object maintaining its own distinct seed array.

Sometimes using Test::More's is test isn't good enough. Its diagnostics may make it easy to miss differences between strings. By using is_binary instead of is, the "!" tells us that the lines differ, and we can quickly scan the bytes that make up the line to see which differ. When comparing very long strings, we can stop after we've seen a few differences.