How to best run all tests in batch (nightly process)

LegacyForumLegacyForum Posts: 1,669 ✭✭
edited December 2016 in SOAtest
Looking to 'automatically' find all tests in a folder structur
(SOAtest V6.1)
We want to test a large number of Web Services as part of an SOA implementation and we'd like each
service's tests to be in it's own .TST file.

The developer responsible for each service is responsible for maintaining the tests for that service and can locally run those tests on his or her own PC.

We use subversion and we'd like the nightly build to update from subversion and then run each Web Service's tests.

We have a folder structure that looks like this:

[Batch-Testing] (square bracketed folders are added to subversion)
....[configureation]
....[documentation]
....global-output
....SOAtest-workspace
....[SOAtests]
........[service1]
............[SOAtest]service1.tst
............output
........[service2]
............[SOAtest]service2.tst
............output
........[service3]
............[SOAtest]service3.tst
............output
........[service4]
............[SOAtest]service4.tst
............output

As each service's tests are created the responsible developer adds a subfolder below the [Batch-Testing]
folder.

We've found that if we add each project into the Eclipse workspace ('SOAtest-workspace' folder) that
we can run SOAtest's CLI in batch and all tests will be executed.

One thing I'd like to be able to do is configure the batch testing so that we didn't have to go into
the batch test's SOA-test-workspace and add each project as it becomes available. We have hundreds of
services to test and if we ever had to move or re-install the nightly batch logic we'd face a LOT of
time re-adding a project for each web service.


Is there anyway I can configure the nightly build or the subversion folder structure so that the web
service tests will be 'automatically' be picked up without my having to add each one to the workspace?

Things I've thought of:

- Use the -resource option of the CLI and point it at the [SOAtest] directory. This doesn't seem to work
and I'm guessing that the CLI doesn't search subfolders. (or was this pilot error? I though I got it to
work once.)

- Use the -source option of the CLI and point it at the [SOAtest] directory. This doesn't seem to work
either.

- Put the SOAtest-workspace directory under subversion. Then I can simply checkout the whole folder
structure and pick up the project references for free. Will that work?

Tagged:

Comments

  • LegacyForumLegacyForum Posts: 1,669 ✭✭
    Hi Chuck,

    Workspace folders contain projects, and each project is in a folder. Here at Parasoft, we check each project folder into RCS (we use CVS, but SVN will work also). Then, our nightly process checks out each of these project folders and then runs these tests from the CLI. This works because the RCS will grab new files and update modified ones - and SOAtest will automatically refresh the workspace when run from the CLI.

    In this case, you could do the same thing by moving the SOAtests folder into the workspace (Actually, you might just create a new project in the workspace called SOAtests, then checkout the SOAtests folder into the project folder by the same name).
  • LegacyForumLegacyForum Posts: 1,669 ✭✭
    Thanks Brian.

    That seems to do the trick. I've modified our folder structure to use the folder where we have the tests as the SOAtest workspace:
    [Batch-Testing] (square bracketed folders are added to subversion)
    ....[configureation]
    ....[documentation]
    ....global-output
    ....[SOAtests] <--SOAtest Workspace
    ........[service1]
    ............[SOAtest]service1.tst
    ............output
    ........[service2]
    ............[SOAtest]service2.tst
    ............output
    ........[service3]
    ............[SOAtest]service3.tst
    ............output
    ........[service4]
    ............[SOAtest]service4.tst
    ............output

    All .TST files in the [SOAtests] rooted directory tree are found and executed. Just a quick question. I'm assuming that we should NOT place the .metadata directory of the workspace under subversion. Is it also a good idea to tell subversion to ignore the individual projects' .parasoft and .project files under that directory?

    Thanks!
    ~chuck
  • LegacyForumLegacyForum Posts: 1,669 ✭✭
    Hi Chuck,

    You are correct - the .metadata folder shouldn't be in RCS - this is a folder that is part of the workspace and is specific to the user's machine.

    In regards to the .parasoft and .project files, you can either add them to RCS or not - it's up to you. The .project file contains information about the project itself - which is probably not relevant if the projects are nothing but .tst files (they are used more for Java and other types of projects). The .parasoft file contains local settings for specific .tst files, so it may be needed (you can open it with Wordpad to see if anything is saved in there). Most of the time, neither file is required.
Sign In or Register to comment.