La liste de diffusion est fermée depuis juillet 2022, mais sert toujours d'archive d'informations sur QF-Test.
Cependant, si vous souhaitez rester informé des nouveautés concernant QF-Test, vous pouvez simplement vous abonner à la newsletter :
abonner à la newsletter
[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. Cookies fonctionnels
Nous utilisons des cookies fonctionnels pour garantir la fonctionnalité de base du site web.
2. Cookies de performance et de statistique
Nous utilisons Matomo pour analyser et améliorer notre site web. Des cookies permettent une collection anonyme des informations qui nous aident à vous offrir un visite clair et facile à utiliser de nos pages web.
This cookie contains a unique, pseudonymized visitor ID internal to Matomo for recognizing repeat visitors.
This cookie is used to track from which website the anonymized user proceeded to any page or sub-page.
The Matomo session cookie is used to track the visitor's page requests during the session. The cookie is automatically deleted at the end of each session (website visit), at the latest after one day.
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.