Paul,
Here is how I am doing it.
I run my tests using test::unit, the same as you. I have organized my tests
into logical groups of test methods, each contained in its own test file.
The framework is flexible and supports running tests as 1) a single test
method, 2) a test file (all test methods in a single file), or 3) a test
suite (set of files).
I try to keep my test framework as simple as possible. I find that xUnit
assertions combined with some simple log output is sufficient for my needs
right now. This approach is quite flexible. I can easily switch between test
environments, users and test sites. Each test is discrete and does not
depend on any other test. All test files are in a single directory by
project (again, to keep it simple).
I have the following "core" files:
common.rb
constants.rb
testrunner.rb
plus many test files.
Here is how they work:
1) common.rb
This is a module file and includes setup and teardown methods (called by
every test method from all test files; read up on test::unit for details),
as well as methods to start IE, clear cache files, log test execution, login
to AUT, etc. Common stuff.
common.rb is where I reference required libs. The file starts like so:
require 'watir'
require 'test/unit'
require 'test/unit/ui/console/testrunner'
require 'watir/testUnitAddons'
require 'yaml'
require 'constants' # My constants file
module Common
def setup
...
end
def teardown
...
end
...etc.
Check out "Programming Ruby: The Pragmatic Programmer's Guide" for more info
on modules.
2) constants.rb
As the name implies, just constants. ;-) The file is nothing more than a
list of constants used by my tests, such as paths and some test data that
rarely changes (and does not change during testing).
3) testrunner.rb
My test suite file, modeled after after
C:\watir_bonus\unitTests\core_tests.rb (see Watir unit tests)
As for the test files, each file starts like so:
require 'common'
class TC_Example01 < Test::Unit::TestCase
include Common
def set_test_defaults
...
end
def test_001
...
end
I use a template with the above code for starting new test files.
Some notes-
As the test methods are logically grouped within a file, I made the decision
to put test data in my test files. I tried different ways, but ultimately
found this easiest when developing new tests. The method "set_test_defaults"
is called from each test method that needs access to the data. As well, each
test method calls a "log_test" method (in common.rb) to spit out some useful
information as the tests execute.
Answers to your questions are inline, below.
Hope this helps!
Sean
--
Sean Gallagher
CRM Quality Assurance, Ticketmaster
[EMAIL PROTECTED]
> Now, if I break out "test_a_somename" into a separate script,
> what is the correct format for calling/running it from within
> the master script?
Use require
>
> In the new sub-script, do I have to repeat the "class
> TC_blahblahblah < Test::Unit::TestCase" structure, or just
> put the "test_a_somename" structure?
Yes, you must extend Test::Unit::TestCase
Do I have to re-include
> all the require/include lines that were in the master script?
> (I don't think I should, but I'm not sure.)
For the approach that I use, yes.
>
> If I have methods that are defined in the master script, will
> they be properly called from one of the sub-scripts, or do I
> have to put them in the sub-scripts too? (I expect it to work
> if they're only defined in the master script.)
No, best to put common methods in a module.
>
> Please forgive these basic questions. I searched the message
> archives but I couldn't find anything helpful other than "you
> should break up large scripts into smaller ones when they get
> too long (like ~ 1000 lines)". And I haven't had any success
> scanning the other Ruby/Watir documentation to give me
> practical advice on how to do this either.
No problem. Happy to help.
>
> Paul.
>
>
>
_______________________________________________
Wtr-general mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wtr-general
