Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Re: proving something other than perl

by Solo (Deacon)
on Jan 24, 2007 at 19:05 UTC ( #596311=note: print w/replies, xml ) Need Help??

in reply to proving something other than perl

And now I have to move to a new platform to test it all again. The setup script should be close to what I need, but, of course the stuff I typed at the command line needs to be rewritten on the new machine...

Are you asking about building your build scripts? I don't see why build scripts can't be treated as another package. The Unix way to handle cross-platform builds is configure (the docs even say there is Win32 support). The Perlish way is Module::Build or MakeMaker.

If you don't want to carry Perl around, it sounds like you may just want a variant of make clean that only impacts the 'build scripts', whatever they are. Makefiles are not Perl specific, all the platforms you mention should have a version of make (nmake for windows).

Or, maybe I've missed your point entirely.


You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.

Replies are listed 'Best First'.
Re^2: proving something other than perl
by Tanktalus (Canon) on Jan 24, 2007 at 19:16 UTC

    The top part is the part where I explain how I got here. Unfortunately, that may be overemphasising that part, as my real question is: anyone who has started to use the "prove" tool (or, really, any of the Test::* namespace) to test stuff that isn't perl, do you have insight on how to approach this? Is there a particular Test::* module that is well-suited? Are there gotchas to using the Test::* modules in such a way? Obviously, things like "require_ok" or "isa_ok" or "can_ok" are useless. I'm more looking for "don't rely on XYZ to work against qx//" or "Check out Foo::Bar - its Quux function can really help with ..." or things like that.

      Strictly speaking you can "prove" using some wrapped up TAP output! for example a file can be sent (system perl, curl, sftp etc..) to any prove-abled server (if you don't want to speak apache, Net::Server or HTTP::Server::Lite with a trivial CGI comes to mind).

      Now about the OP question: build systematically wrappers for processes-to-be (created from C, C++, java -- for java you often need a wrapper anyway for classpath and libs) and you use the OS (i.e the shell exit status). It is not really tough to generate TAP output, is it? (tee is useful). For a given process, I keep the output of one "correct" run in one file, and compare subsequent ones with that reference file. Some of the basic infrastructure can be automated and some templates are useful (output files can be generated by perl in another machine if you like, but with a decent shell, shell eval is your friend!)

      Welcome to the world of "external testing" it is much harder than the other one so that's why you don't see much of it ;)
      a good shell is ksh that you can get from, grab ksh93s for all the platforms that lack a decent shell; for cygwin (windows!) I recommend using still ksh93r (as there are problems that I will soon report to the ast-users list) and by the way, to use ksh on cygwin you don't need the whole cygwin stuff just the cygwin1.dll and maybe a few commands like curl and tar). So you make your little shell tarball where you don't have a decent shell. Also the perl that comes with the system can obviously be useful and can COOPERATE HEALTHILY with the shell and other commands, no? ;)

      % stephan@armen (/home/stephan) % % cygcheck /usr/ast-ksh93r/arch/cygwin.i386/bin/ksh93r.exe C:/cygwin/usr/ast-ksh93r/arch/cygwin.i386/bin/ksh93r.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:/cygwin/usr/ast-ksh93r/arch/cygwin.i386/bin\cygshell11.dll C:/cygwin/usr/ast-ksh93r/arch/cygwin.i386/bin\cygast54.dll C:/cygwin/usr/ast-ksh93r/arch/cygwin.i386/bin\cygcmd12.dll C:/cygwin/usr/ast-ksh93r/arch/cygwin.i386/bin\cygdll10.dll
      hth --stephan
      the un*x way? cooperation!
      test stuff that isn't perl

      Apache::Test is the biggest example that comes to mind. I've also used Test::Output, but not in a while.


      You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
      The reason I wrote prove was so that I could test PHP scripts along with the rest of my Perl programs. The key is to create a Test::Harness::Strap module that does the right thing, and to load that strap with the --strap argument on the command-line.

      I know it's hardly a complete answer, but I hope it gets you pointed in the right direction.


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://596311]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (6)
As of 2021-07-23 18:15 GMT
Find Nodes?
    Voting Booth?

    No recent polls found