The mailing list has been closed since July 2022, but continues to serve as an archive of information about QF-Test.
But if you want to stay informed about news about QF-Test, you can simply
Subscribe to Newsletter
To get up-to-date information about each release - including minor releases - you can
subscribe to the RSS feed or follow us on social media.
Alternatively, QF-Test also provides release information itself.
Another source of information is our blog, where there are current articles on general topics, on the company QFS and also various "how-tos"
subscribe to blog
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [QF-Test] Date and time localization of the test cases
Hello Marek, you didn't specify in what way you need to handle those date formats. They could be features or labels (extra feature) of components, the name of a sub-item, a value to check or some text you need to enter. Using variables is a one-size-fits-all solution. For features, extra-features and checks you could alternatively implement the respective Resolver or Checker as described in manual sections 41.1 (Resolvers) https://www.qfs.de/en/qf-test-manual/lc/manual-en-tech_resolversmodule.html#sec_resolversmodule and 41.4 (Checkers) https://www.qfs.de/en/qf-test-manual/lc/manual-en-tech_checkers.html#sec_checkers Finally, you could implement a function in a Jython or Groovy server script that does the transformation and use that on the fly, e.g. (Jython) global transformDate global dateFormat = ... whatever ... def transformDate(date) ... do the transformation into dateFormat ... Make sure this script is run at the beginning of your tests. Then you specify the date everywhere in its default form e.g. the European format and wrap it in a Jython call, e.g. ${jython:transformDate("13.03.2017")} or if the date is already variable ${jython:transformDate(rc.lookup("datevar"))} The above can be used in all the places I mentioned, i.e. the respective attributes of 'Component', 'Check' or 'Text input' nodes. To change the target format, just run a server script with global dateFormat dateFormat = ... some new format ... Best regards, Greg "Nedvěd, Marek" <m.nedved@?.de> writes: > Hello fellow testers, > > Today I would like to ask on some tips how to handle different time and date formats in the tests. The tests that I > have written were all expecting the dates in the European format (dd.MM.yyyy) but now we have also the application > with British locale, so all dates look different, and what worse, there is now difference between the short, medium > and long version of the date (16/01/2007, 16-Jan-2007 or 16 January 2007 respectively). > > I would like to avoid either copying everything or inserting “ifs” into the test suites. Are there any other options? > What would be the best practice here? > > Only thing that I came up with is to set a variable before each date instance and convert it by a script to the > specific format. > > Mit freundlichen Grüßen > > Marek Nedvěd > > qualitype GmbH - IT works. > > _________________________ > > Marek Nedvěd > > Softwaretester > > Tel +49 351 8838 2800 | m.nedved@?.de > > qualitype GmbH | Moritzburger Weg 67 | 01109 Dresden | Germany > > Tel +49 351 8838 2800 | Fax +49 351 8838 2809 | www.qualitype.de > > Sitz der Gesellschaft / Head office: Dresden | Amtsgericht Dresden HRB 31753 > > Geschäftsführer / Management: Dr. Wilhelm Zörgiebel | Dr. Frank Götz -- Gregor Schmid E: gregor.schmid@?.de T: +49 8171 38648-11 F: +49 8171 38648-16 Quality First Software GmbH | www.qfs.de Tulpenstr. 41 | 82538 Geretsried | Germany GF Gregor Schmid, Dr. Martina Schmid, Karlheinz Kellerer HRB München 140833
|
1. Functional cookies
We use functional cookies to ensure the basic functionality of the website.
2. Performance and statistic cookies
We use Matomo for analyzing and optimizing our website. Cookies permit an anonymous collection of information that help us offering you a clear and user-friendly visit of our web pages.
This cookie contains a unique, pseudonymized visitor ID internal to Matomo for recognizing returning visitors.
This cookie is used to track from which website the anonymized user proceeded to our website.
The Matomo session cookie is used to track the visitor's page requests during the session.
is created and should be then directly deleted (used to check whether the visitor’s browser supports cookies).
short lived cookies used to temporarily store data for the visit.
short lived cookies used to temporarily store data for the visit.