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.
| [reply] |
Ahhh! That clears things up! :)
Yes, you can do that. Probably the easiest way would be to have your t/my_app_1.t execute the non-perl stuff and return the correct code whether it failed or succeeded.
I highly recommend checking out Ian Longworth & chromatic's Perl Testing - A Developer's Notebook (ISBN: 0-596-10092-2).
Hope this helps.
| [reply] |
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 http://www.research.att.com/sw/download/, 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!
| [reply]
[d/l] |
| [reply] |
| [reply] |
