|
dragonchild has asked for the wisdom of the Perl Monks concerning the following question:
To scrape the rust off my C/C++ skills (and to learn LISP), I've started writing a Zork/ Adventure/MUD type of console game. But, being a good monk, I want to test this thing.
The game runs in a terminal window, accepting typed input and returning text back. Is there a Test::* module to automate the linkage between it and Test::More?
------
We are the carpenters and bricklayers of the Information Age.
Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose
I shouldn't have to say this, but any code, unless otherwise stated, is untested
|
Re: Testing Zork-style game
by tachyon (Chancellor) on Jun 28, 2004 at 17:24 UTC
|
Why not separate the code logic from the display logic MVC style. That makes testing, porting, and putting it online a breeze....
| [reply] |
|
|
How would I test, using the same testing code, a C, C++, Perl, and LISP implementation of the same design? I want to use the same testing code so I can demonstrate that I code the same functionality in different languages. (This is a personal requirement.)
------
We are the carpenters and bricklayers of the Information Age.
Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose
I shouldn't have to say this, but any code, unless otherwise stated, is untested
| [reply] |
|
|
How would I test, using the same testing code, a C, C++, Perl, and LISP implementation of the same design? I want to use the same testing code so I can demonstrate that I code the same functionality in different languages.
You might want to consider producing a scriptable interface to your code base and testing via that. Implement the scriptable API in each language and Bob's your Father's brother.
You might want take a gander at Developing a timeclock application. It's in Ruby, but I think the point comes across.
| [reply] |
Re: Testing Zork-style game
by pbeckingham (Parson) on Jun 28, 2004 at 17:18 UTC
|
| [reply] |
Re: Testing Zork-style game
by andyf (Pilgrim) on Jun 28, 2004 at 18:28 UTC
|
Just a thought. Is the output unique for every state in the game?
If not ( I suspect it isn't - ie you will be in many situations which return "You are in a room with a window, there is one door to the North and one door to the South" coresponding to completely different game states.) then a test suite mapping input to output doesn't prove your implementation in quite the same way. My approach might be to write a function in the C, Perl, and Lisp implementations that dumps the game state in a standard format. Use that in your tests. When you have proved that the same state sequence solves the game, then add your output - the same for every implementation. Interesting to read Knuths take on Adventure! BOL
Andy | [reply] |
Re: Testing Zork-style game
by BrowserUk (Patriarch) on Jun 29, 2004 at 04:56 UTC
|
K.I.S.S. Assuming that your using standard IO for your input and output, your test scripts could do something like:
use File::Slurp;
use Test::More ...;
...
system( 'perl zork.pl < testfile.1 >output.1' );
my $out = Slurp( 'output.1' );
my $expected = Slurp( 'expected.1' );
ok( $out eq $expected );
Substututing zork < testfile.1 > output.C.1 (C-version) or lisp zork.whatever? < testfile.1 >output.lisp.1 for the perl zork.pl in the system command allows you to run the same tests against all three versions.
Adding a debug option (to at least one version) that copies both the input and output to a separate files whilst the game is being played would allow you to generate your tests interactively with that version and then supply the input to the other versions and test their output was the same.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
| [reply]
[d/l]
[select] |
|
|
Except that you'd want to write
ok( $out eq $expected );
as
is( $out, $expected );
If the strings are really long and hard to read through, look at Test::LongString.
| [reply]
[d/l]
[select] |
|
|
| [reply] |
Re: Testing Zork-style game
by sgifford (Prior) on Jun 28, 2004 at 19:53 UTC
|
I'm not sure what kind of linkage you're looking for, but if I were implementing this I'd use IPC::Open2 to open a pipe to and from the game, then just send input and check the output. A bug in your game could cause a hang, so I would also set an alarm before each command.
| [reply]
[d/l] |
|
|
