Intermittent unit-test failure associated with i18next

I am trying to unit test my aurelia custom element, which looks like below.

// BaseText.ts
import { bindable } from "aurelia-framework";
import { BaseI18N } from "aurelia-i18n";

export class BaseText extends BaseI18N {
    @bindable public value: string;
    @bindable public i18nKey: string;

// NormalText.ts
export class NormalTextCustomElement extends BaseText {}

// NormalText.html
    <span t.bind="i18nKey">${value}</span>

Now, I want to test if I change the value of i18nKey, the translated text is shown in the element. To test that, I have written the below test case.

describe("i18n specs", () => {

    let component;
    beforeEach(() => {
        component = StageComponent
            .inView("<normal-text id='i18n1' value='Ignored Text' i18n-key='test'></normal-text>");

        component.bootstrap((aurelia: Aurelia) => aurelia.use
            .plugin(PLATFORM.moduleName("aurelia-i18n"), (instance) => {
                const aliases = ["t"];

                return instance.setup({
                    attributes: aliases,
                    fallbackLng: "en",
                    lng: "en",
                    resources: {         //<-- translation resources
                        en: {
                            translation: {
                                test: "English test"

    it("Should render the translated text with a i18nKey", (done) => {
            .then(() => {
                const spanElement = document.querySelector('normal-text#i18n1>span');
                expect(spanElement.textContent.trim()).toBe('English test');
            .catch(e => { console.log(e.toString()) })
            .finally(() => {

Now the problem is that this test case fails intermittently, which surely is going to be a problem with CI. I suspect that it has something to do it the initialization of i18next, and the test case is running before the initialization is complete. Though I am not very sure about this hypothesis.

What should I change, so that this test case becomes deterministic?

Additional info:

  1. This test case succeeds if it runs before every other view related test cases.
  2. I have created a GitHub repo, so that interested reader/user can reproduce the problem. Please keep in mind that you might have run the tests multiple times to replicate the issue.

P.S. I have asked the same question on SO. A response here or in SO, would be really great :slight_smile:

Thank You.

Hmm that looks good, not sure what it could be on first look. I’ll take a look at your repo in friday.

1 Like

While we are at it, I would like to point out another issue.

I have added another custom element which is almost similar to the nature of my previous custom element (differing in only view). I have added a few test cases also for this new custom element. However, this time, some test cases threw error on xyzElement.textContent (as shown before) saying xyzElement is undefined. This resulted in below error.

Spec ‘HERE_GOES_SPEC_NAME’ has no expectations.

It seems that when all tests are ran together, they are not running in complete isolation, which may result in premature and erroneous cleanup of resources. However, this does not happen with a particular test suite every time, as can be seen below. However, when each test suites are run individually, associated test cases run fine (needless to say that the original issue regarding to i18n still remains).

I found the solution of the original problem, and posted a SO answer.

After some debugging for the second issue, it seems that needed view-model and controller is not available for the second suite of test cases. Here second can either of 2 controls as said above, as test cases and suites are randomly ran. And due to this missing controller/viewmodel, the view is not completely generated. For example, it generates something like <normal-text value="Hello Static Text"></normal-text>, but without the inner span. Which is the reason behind the failing test cases. I have also asked this question on SO. Any suggestion/solution would be immensely helpful.

Great to hear you found the solution to your primary problem and it seems related to the second one. I had this behavior once in the i18n test suite itself. Now we know what to focus on. I’ll ping back when I know more.

1 Like

Awesome :slightly_smiling_face:

@zewa666 I have found a workaround for the second problem. I have reported the workaround here, and opened an issue in aurelia/metadata repo.

This is awesome, I’ve pinged the team internally to see how we can go forward with this new insights

1 Like