2019 bis heute  2018  | 2017 2016 2015 2014 | 2013 | 2012

Mailingliste - Einträge 2012

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[QF-Test] Test case design in QF-Test -- How far is too far?

  • Subject: [QF-Test] Test case design in QF-Test -- How far is too far?
  • From: "Berg, Klaus-Peter" <klaus-peter.berg@?.com>
  • Date: Tue, 14 Feb 2012 12:29:15 +0100

Hi all,

in Unit Testing (e.g. with a xUnit framework) we have the "mantra" of "self-contained" tests, and so called "test fixtures" [http://en.wikipedia.org/wiki/Test_fixture]: 

Test fixture refers to the fixed state used as a baseline for running tests in software testing. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable. 
Frequently fixtures are created by handling setUp() and tearDown() events of the unit testing framework. In setUp() one would create the expected state for the test, and tearDown() would clean up everything what had been set up.

This way, we really have independent tests.

However, is this mantra also valid (and needed) for end-user GUI-based tests done with QF-Test?

In JUnit, e.g., a Test Class could be seen as the equivalent of a Test-set, where the test class is a container for related test methods (=test-cases).
Does this mean for our QF-Test suites that EVERY Test-set has to have a SETUP node as a starting point and a corresponding CLEANUP node at the end? 

Setup and Cleanup are executed for each test contained in the Test-set, as it is done with setUp() and tearDown() for every test method in a JUnit test class. 
However, JUnit goes even one step further: JUnit provides a *new instance* of the fixture objects for each test method!

So, how far is too far? Starting the SUT from the ground up in every Test-set's Setup node? And stopping the SUT (often done with a "File->Exit" menu click) in the CLEANUP node?

Does the QF-Test community has some guidelines for this aspect of test design, including the role of QF-Test dependency usage?
And: Is it valid that a test pre-condition (either expressed by a Setup node or a dependency) is a "test in itself, e.g., dependency "isProjectViewOpen" is a *check* (i.e., a kind of test) that this window has been opened correctly and is showing to the user...

Would be interesting for me to get the opinion of others in order to add "new dimensions" to my test design ;-)
Best regards
Klaus Peter