Well, not exactly what I had in mind...

Post #244,538 by Arkadiy 2/14/06 12:01:13 PM Reply	Well, not exactly what I had in mind... \ntestDescription(<<end);\nThis test checks that widgets can mate with thingamaboobs\nend\n\n\ntestStep("create a gray widget");\n...\ntestStep("create a red thigamaboob");\n...\ntestStep("mate the widget and the thigamaboob");\n...\ntestStep("verify that the result is gray with red stripes");\n\n In my previous implementation, I used the following \ntestDescription(<<end);\nThis test checks that widgets can mate with thingamaboobs\n\n- create a gray widget\n- create a red thigamaboob\n- mate the widget and the thigamaboob\n- verify that the result is gray with red stripes\n\nend\n\n\ntestStep();\n...\ntestStep();\n...\ntestStep();\n...\ntestStep();\n The test support code would parse a bunc hof " - xxx" at the end of test descrioption, and use them to notify the user of test step being taken. That, of course, was quite fragile. More importantly, the self-documenting value of testStep was completely lost. So the question is - how do I extract the test steps from the code? I was thinking about using compilation pass. Now that I look at it again - it seems that I could open the script file from inside testDescription, and grep for testStep() - God forgive me. ------ 179. I will not outsource core functions. -- [link\|http://omega.med.yale.edu/~pcy5/misc/overlord2.htm\|.]
Post #244,589 by ben_tilly 2/14/06 6:35:14 PM Reply	You can get where you want to go But I wouldn't suggest going there. If you're going to write normal Perl, write normal Perl. If you're not going to write normal Perl, make it look like it isn't normal Perl. With source filters you can do what you're asking for. However your maintainance programmer will (or at least should) hunt you down with a blunt weapon. But consider something like this which has (modulo syntax) the exact same structure as your program: \nEND {\n # This is executed last, even though it appears first.\n print "This test checks that widgets can mate with thingamaboobs\\n";\n show_plan();\n do_plan();\n}\n\nplan(\n "create a gray widget",\n sub {\n ...\n }\n);\n\nplan(\n "create a red thigamaboob",\n sub {\n ...\n }\n);\n\n...\n\n This is easy to implement, does what you're asking for, and it is fairly obvious to the maintainance programmer how the magic works. Incidentally if you're doing automatic unit tests, is there a good reason not to be using Test::More? Perl has good facilities for such test suites, you just have to use them. (Ignore this comment if the point of your test suite is to have someone look at the screen and manually review that what shows up matches what was supposed to show up.) Cheers, Ben I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
Post #244,613 by Arkadiy 2/14/06 9:19:17 PM Reply	OK, I'll consider your idea The thing is, this stuff will be used by people who don't know Perl and (probably for that reason) don't love Perl. It takes all my efforts to get them to use my framework at all. If I have to explain constructs like plan("xxx" sub{...}) I'll never get anything done at all; The framework I am using is not for unit test - it's for system tests. It has two main classes - Executable and FileTail. One starts a process and lets me send to its stdin, and the other lets me tail a file. This is used in the context of our runtime environment, starting clients and servers, feeding data and checking what comes out. I am not sure how Test::More would help me there. ------ 179. I will not outsource core functions. -- [link\|http://omega.med.yale.edu/~pcy5/misc/overlord2.htm\|.]

Welcome to IWETHEY!