2017 up to now  | 2016 | 2015 | 2014 | 2013 | 2012 | 2011 | 2010 | 2009 | 2008 | 2007

(older archive entries before 2007 are not shown here, but included in the onsite-search)

Mailing List - Entries of 2012


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

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


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

Hello Greg,

the concept of Dependencies in test design is quite useful indeed and it can replace the practice described by another forum user who wrote "Each individual test has a setup and cleanup so it can run by itself". It may be that "'Dependencies' will feel almost like magic when you run several non-related 'Test-cases' and all setup and cleanup is handled automatically" [http://www.qfs.de/qftest/manual/en/user_dependencies.html].

However, despite all this enthusiasm and all the advantages, it should be mentioned that dependencies are not only complex -- as you already wrote: dependencies may FEEL like magic but they ARE NOT MAGIC in a sence, that they do not come for free! Linearizing combined dependencies, dependency stack handling, dependency related variables, execution in Test-suite or Test-set nodes according to the setting of a "'Always execute, even in test-suite and test-set nodes'" checkbox, etc. etc. -- the QF-Test runtime system really takes a lot of burden from the test implementer. Nevertheless, it is the JOB of the TESTER to implement all dependency logic in a very robust way (using try/catch, error handler, etc.). If we just look at the implementation of a "simple" dependency "sutStarted" for the famous CarConfigurator, we can see that there is 
-- Worse Luck! -- NO QF-Test "magic" that does this job for us, e.g. as a simple procedure call. It is (and will remain) the job of me, as a test implementer, who still has to create all this fancy "check if the dependency is fulfilled" stuff properly -- and that is for me the second important topic (besides complexity) when it comes to think about "using" dependencies: "Effort"! 

We always have to remember that dependencies are (IMO) a framework -- not a tool, ready to use... 
There ain't no such thing as a free lunch, ;-)

Best regards,
Klaus Peter