Re^2: UnitTesting multi-threaded apps

You wrote:

As an aside, why are you using "PerlUnit"? Are you new to Perl?

LOL! I have been using Perl since 1995! Also Java, Python and PHP.

I often see this with programmers coming from other languages to Perl looking for the Perl equivalent of JUnit. The mainstream Perl QA community overwhelmingly uses the core Perl Test::More module, along with the prove command and CPAN Test::More-compatible modules. If you need something like JUnit, take a look at Test::Class.

Well, I went with PerlUnit, because I had been using jUnit, pyUnit and phpUnit quite happily and wanted to use the xUnit equivalent for Perl.

I have 640 tests written in PerlUnit for my application, so I am not really keen to switch in this particular project, but I might consider other frameworks for future projects. Can you tell me a bit more why the Perl commmunity does not use PerlUnit? What are the advantages of these other frameworks you mention? Would any of them solve my multi-threading test problem?

BTW: I just looked briefly at Test::Class, and I am not sure it would work for me because it's not object oriented. And testing an object-oriented app with a non-object oriented test framework doesn't work well for the following reason:

Say you have a class hierarchy like this:

ParentClass
   ChildClass1
   ChildClass2
[download]

There is some behaviour that the two children inherit from their common parent. This behaviour needs to be tested of course. If your test framework is not OO, then you will need to repeat those same tests in the tests for both children. But if your test framework is OO, you can create a parallel hierarchy of tests cases:

ParentClassTest
   ChildClass1Test
   ChildClass2Test
[download]

The tests for the parent class behaviour are defined in ParentClassTest, and in tests for the children only need to test that part of the behaviour which is specific to them. This is a standard testing best-practice, and I have found it to be really useful. But it requires an OO test harness. Thx

Comment on Re^2: UnitTesting multi-threaded apps Select or Download Code

Replies are listed 'Best First'.
Re^3: UnitTesting multi-threaded apps by BrowserUk (Patriarch) on Mar 11, 2011 at 14:08 UTC
Unfortunately, the meaning of the term "unit testing" seems to have been lost, or supplanted. Unit testing should (did) mean testing a 'unit' of an application, and was only one of several forms of testing. It nows seems to have taken on a different meaning entirely, and to the detriment of everyone. In a multi-threaded application (or multi-processed) application, unit testing should not require any concurrency. Each thread procedure should be tested (and testable) in isolation. That is the very definition of 'unit testing'. Once unit tests have been past, then you move to the next level of testing, 'Integeration tests'. Where you bring those units together and test that they integrate. Integration testing inevitably does not (often cannot) fit with the OK/Not OK pattern of results required by these unit testing frameworks. But, as is often the case with silver bullet development paradigms, the counting of OKs & NOKs has become more important than what they simplistically represent, and so you arrive at the situation where people attempt to force fit all their phases of testing into the unit testing mould. The fundamental issues of integration testing (and systems testing if anyone still does it), especially in concurrent systems, are such that they cannot (and should not) be forced into simplistic, static Yes/No tests. They need to consider the effects of non-determinism upon the interactions between units of concurrency. And that invariably requires running the integrated units together over time and monitoring both the content and timing of their interactions. Doing this well, or even at all, with a fixed sequence of static binary truth tests simply isn't possible. Attempting to force fit intgration testing into the unit testing mould for the sole purpose of the statistics produced is counter productive in the extreme. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^3: UnitTesting multi-threaded apps by eyepopslikeamosquito (Archbishop) on Mar 11, 2011 at 21:17 UTC
Can you tell me a bit more why the Perl commmunity does not use PerlUnit? PerlUnit seems to be have been abandoned. To put that to the proof, you might like to ask your question on the PerlUnit mailing list and see what sort of response you get. OTOH, the author of Test::Class is an active member of the Perl qa community, fixes bugs quickly and makes regular releases. Test::Class is more Perlish, works with other Test::Builder based modules and has excellent community support. This is all discussed in the Test::Class documentation. As for why PerlUnit never seemed to gain traction in the Perl community, that is an interesting question. My guess is that it is mainly cultural: Perl has a long tradition of testing and qa, it worked well, folks were keen to further improve it and saw no reason to switch to an xUnit-based framework. Perl has a thriving qa community and continues to hold well-attended Perl QA hackathons. Also, Perl is a multi-paradigm language (in constrast to OO-only Java where JUnit rules). Notice that multi-paradigm C++ has similarly not embraced an xUnit framework the way Java and C# (NUnit) have.	[reply]