Added Symfony Translation assertions

[TavoNiievez]

Examples:

    $I->amOnPage('/register');
    $I->dontSeeFallbackTranslations();
    
    $I->amOnPage('/');
    $I->dontSeeMissingTranslations();
   
    $I->amOnPage('/register');
    $defined = $I->grabDefinedTranslationsCount();
    $I->assertSame($defined, 6);
   
    $I->amOnPage('/login');
    $I->seeAllTranslationsDefined();
    
    $I->amOnPage('/register');
    $I->seeDefaultLocaleIs('en');

    $I->amOnPage('/register');
    $I->seeFallbackLocalesAre(['es']);

    $I->amOnPage('/register');
    $I->seeFallbackTranslationsCountLessThan(1);

    $I->amOnPage('/');
    $I->seeMissingTranslationsCountLessThan(1);

[TavoNiievez]

@ThomasLandauer @cs278 @W0rma @xEdelweiss please review.

[ThomasLandauer]

I've never used translations, so I can't say much. Just one idea for the 3 ...CountLessThan() methods:

• Why don't you assert the exact number? ...CountEquals()?
• Or maybe just return the number with grabTranslation...MessageCount(), then have the user assert whatever they want?

[xEdelweiss]

This looks like a great addition! I have a few suggestions:

The function names feel a bit verbose. What do you think about simplifying them to something like:

• dontSeeMissingTranslations()
• dontSeeFallbackTranslations()
• dontSeeDefinedTranslations()
• seeMissingTranslationsCountLessThan()
• seeFallbackTranslationsCountLessThan()
• seeDefinedTranslationsCountLessThan()

I do not know what Defined means in the context of Translations. But if it's a translation that is not fallback or missing, then it would be great to have seeAllTranslationMessagesDefined() (or seeAllTranslationsDefined()) as an alias for dontSeeTranslationMissingMessages() + dontSeeTranslationFallbackMessages().

Silly question: shouldn't the translation locale be the same as the locale? :)

[TavoNiievez]

Hi @ThomasLandauer @xEdelweiss Thanks for the suggestions! I have reviewed the methods and applied some changes:

• I renamed the methods to shorter versions (e.g., dontSeeMissingTranslations() instead of dontSeeTranslationMissingMessages()).
• I kept the “less/greater than” approach for methods that compare translation count, the idea behind this is that some people/teams may have an 'acceptable' value of missing translations and these assertions serve to ensure that such a limit is not exceeded, rather than causing the test to fail whenever a single translation is added or removed.
• I added a new assertion (seeAllTranslationsDefined()) to encompass checking for missing and fallback translations, as in many cases it simplifies the “all is defined” check.
• I renamed seeTranslationLocaleIs to seeDefaultLocaleIs, which is closer to what you see from the Profiler GUI.

Any additional comments?

[ThomasLandauer]

Yeah, the shorter names are indeed better IMO.

• But I would rename grabDefinedTranslations(): You're not grabbing the actual translations, so it should be something like grabDefinedTranslationsCount or grabNumberOfDefinedTranslations.
• About the ...TranslationsCountLessThan() approach, after some more thinking about it: What I don't like is the overall notion that some errors are OK. To me, this sounds like seeElementSometimes()... If Codeception had an HTML validator built in, I also wouldn't want it to be called seeHtmlErrorsLessThan(). To me, this is not what a testing framework should propagate. I didn't really doublecheck, but I think this would be the only method in Codeception which does something like an "estimation".

But again, I'm not using translations, and since you're the one who did the work, you're free to decide what you need/like best :-)

[TavoNiievez]

@ThomasLandauer good catch on grabDefinedTranslationsCount, I've already corrected it :)

The analogy with html errors is not exactly fair, since there is randomness in your example, while here the number of missing translations will grow deterministically by specific changes made in the code. I'm not sure if outside of the Symfony module there are any others, but seeRequestTimeIsLessThan is similar, although I wrote that code too haha.

I've encountered applications where it's difficult to maintain 100% translated messages, and in this particular case a non-strict assertion seems to me the most useful.
Besides it is an option, if someone wants to assert values of zero there are the dontSee methods.

[ThomasLandauer]

Ahem, HTML errors are deterministic too - if you adhere to the specs, you have 0 errors in each run. seeRequestTimeIsLessThan is an excellent example, cause nobody would ever want to assert seeRequestTimeIsExactly(802) ;-)
And exactly because the translations are deterministic, I think the grab approach is possible, since you'll always get the exact same number.

But it's not that important. You're the boss -> just merge it! :-)

[TavoNiievez]

😕 I'll move on, but because I wasn't convinced by your recent arguments, not because of the “You're the boss” thing.