Quantcast
Viewing all articles
Browse latest Browse all 294630

[META] remove t() from assert message

Problem/Motivation

Status

The issue has been open since 2009. It has consensus and the approval of SimpleTest maintainers, and is already part of our documented standard:
http://drupal.org/simpletest-tutorial-drupal7#t

Details

  • The $message parameter of SimpleTest assertions (e.g., DrupalTestCase::assertTrue()) is a string displayed only in the administrative UI or on the commandline following test runs, and on testbot.
  • This parameter is never translated, so using t() on it is needless overhead.
  • We have other instances in core where string function parameters should not be wrapped in t(), e.g. watchdog().
  • When the assertion message is a plain string, t() should simply be omitted.
  • When the assertion message contains placeholders for variables, format_string() should be used instead.

Proposed resolution

  • Strip t() from plain-string assertion messages that are still using it.
    • <?php
      $this
      ->assertWhatever($condition, t('My custom message here'));
      ?>

      Becomes:

      <?php
       $this
      ->assertWhatever($condition, 'My custom message here');
      ?>
    • Assertion messages that have placeholders or variables will be converted to format_string(). This can be done separately if the patch is particularly large. (Mark issues that have already had messages with placeholders converted in the list below.)
    • Other parameters of assertions (beside the message parameter) are not changed.
    • Other uses of t() in automated tests are not changed.
  • Discuss other uses of t() in tests in a separate issue.
  • Consider documenting this practice in the parameter documentation for assertions in a followup issue.

Remaining tasks

  1. Generate patches stripping t() from plain-string assertion messages only (issues below).
  2. Review these patch closely to ensure there are no incorrect changes. Applying locally and using git diff --color-words works well.
  3. Address assertion messages with placeholders separately if the patch is large.
  4. Address followup issues separately.
  5. Post a change notice.

What parts of core are affected?

How will we avoid conflicts with important patches?

  • Testing in July shows=ed that only 4 patches out of 900-some NR 8.x issues were affected by this change.
  • There is no affect on patches that do not include changes to existing automated tests.
  • With no moved files or lines and a simple 1:1 assertion/deletion, the change is straightforward enough that, in most cases, patches and sandboxes can simply be rebased to make them apply on top of the change.
  • We will ensure all issues with the Avoid commit conflicts tag have a compatible reroll in the issue before the change is committed. If you have an important outstanding issue that is close to being RTBC, please add this tag to that issue.
  • If you have an important sandbox for which we should avoid merge conflicts, please post a comment below. Link the sandbox's project page and identify the relevant branch(es).

Related issues

Original report by neochief

Hello.

As one of the active Russian translators, I can state that translation of simpletests asserts' descriptions is totally useless (as it was once before in Schema descriptions). People who run tests are familiar with English.

Maybe we should consider removing those t() from our tests?


Viewing all articles
Browse latest Browse all 294630

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>