i18n tests

[klemmster]

Hi,

is there a way to 'source' data-files explicitly? Basically I'm looking for a way to run the test-suite several times with identical keys but different values. Is that possible from within watai?

[MattiSG]

Hi Richard!

No, there is currently no way to explicitly load data files (or any kind of file, for that matter).

However, here are two ideas for achieving the goal of switching datasets at runtime.

Symlinks

Duplicating the test suite by symlinking all files but the data file you want to change. This is of course quite ugly, but is easy to setup and is the main workaround the current lack of reusability of any pieces (one could have the same problem with features or components).

Export variable datasets

The data files themselves are pure JS, so you could declare the different values based on a config switch.

Example:

    // integration/VariableData.js
    var localizedGreeting;
    if (config.language == 'en')
        localizedGreeting = 'Hi';
    else if (config.language == 'de')
        localizedGreeting = 'Hallo';

    // integration/LocalizedHeaderFeature.js
    description: 'Users should be greeted in their own language',
    scenario: [
        {
            Header.greeting: localizedGreeting
        }
    ]

    # invocation:
    $ watai integration --config '{"language":"de"}'

---

Obviously, none of these solutions are very clean. I am collecting usage information to find the best answer to reusing / switching parts of test suites, as it seems to be a requirement when they grow bigger. We have different approaches envisioned for 0.7 or 0.8. I would be glad if you could describe a bit more of the context, and how acceptable the solutions above are for your use case :)

Hoping to have answered your question, Best regards, Matti

[klemmster]

Hi Matti,

thanks for the fast approach. I should have mentioned that I'm aware of the possibility to just do symlinks, but as you mentioned it doesn't seem to be a clean solution. The variable data set approach seems to be fairly reasonable.

The context should be fairly common: A browser based application that's supposed to support multiple languages. (German, French and English in our case, but that shouldn't make a difference). It's a fairly dynamic approach, as the language to display can change at least in 3 places.

1. The login screen: The user is presented a default language based on his/her browser settings or cookies
2. After login, the language changes to the users preferred setting
3. The language changes if changed in the settings (immediately, no logout/login procedure)

Thus the most comfortable way to test this would be dynamic in watai, too. I think the variable data set is fairly close, given that the config can be changed at runtime. (I will check it out)

Without having thought it completely through, having a namespace style approach would make the data file clearer. Namespacing could be approached by an optional namespace in the filename with a fallback to default values (e.g. no namespace) if the key is missing. Filestructure:

integration/VariableData.js
integration/__DE_VariableData.js
integration/__FR_VariableData.js

pro: This makes it fairly painless to add these kinds of tests later on, having default tests first and enhance them as it's needed

con: one has to manually keep keys in sync, if that's really a problem.

I hope I could give you some insight in the context and thanks for the good work. It's been incredibly useful!

With best regards,

Richard

[MattiSG]

Thank you very much for these details, Richard :) It’s really helpful in order to design a proper and usable solution.

I really like your “namespacing” idea. I will draft a description of such a convention in a separate issue. The con you gave for it is, I think, the cost to pay for full separation. The only way to avoid it is probably to use disjunctions such as the one given in this “variable data set” idea. We could lower their cost by providing helpers, but the end result would always be the same.

Best, Matti