SPONSORS:






User Tag List

Results 1 to 3 of 3
  1. #1
    Junior Member
    Join Date
    Nov 2000
    Location
    Nashua, NH, USA
    Posts
    27
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Phase 2 - Starting to use Silktest - Setting test files

    After taking the advise from the group, I have taken an opportunity to just check out SilkTest and get a feel for it. Please understand, I am new to automated testing and setting this all up on my own without any help. I now would like to start setting up test. I was wondering if you should setup one large test that includes the smaller test in one file or should I make a directory and have files within. I obviously will need to link these test to run them but have them broken down to be able to update the individual pieces. Could you all please "tell me where to go" from here. Thanks.

    ------------------
    Rowland
    Rowland

  2. #2
    Senior Member
    Join Date
    Aug 1999
    Location
    MA
    Posts
    129
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Phase 2 - Starting to use Silktest - Setting test files

    You should start with small test files.

    A test should do one "thing", and do it well. It is good practice to use subdirectories and multiple files laid out on the filesystem in a logical manner.

    Putting everything into several files in a flat directory structure is the recipe for disaster, if your company embraces SilkTest.

    [This message has been edited by styler (edited 11-28-2000).]
    Steven Tyler
    Manager - Performance Engineering

    Kronos Incorporated
    tel: +1 978 947 4219

  3. #3
    Junior Member
    Join Date
    Sep 2000
    Location
    Beaverton, OR USA
    Posts
    27
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Phase 2 - Starting to use Silktest - Setting test files

    I agree completely. Creating very large test files, in my experience with Silk, tends to create massive dependencies, which in turn is hell to debug and/or maintain. I inherited an acceptence test from somebody who threw together all sorts of functionality testing into one massive test file, and between all the research it took to find out dependencies and variable assignments etc. I could have re-written a large chunk of it.

    Unless you are creating a huge suite of tests (thousands), you really can't go wrong with parring down as far as possible the function of your testcases. Like the above message says, they should do one thing and do it well. This makes it easy on everyone -- the designer, the operator, and the debugger, if they happen to be different people. ;-)

    Andrew

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.0.9 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Questions / Answers Form provided by vBAnswers (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominatevBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 09:26 AM.

Copyright BetaSoft Inc.