1

I have a program already internationalized with gettext module, however it bugs me for days whether should I centralize the strings (make them variables, so they can be referred by the main program or the tests suite) inside one module or not. If they are not centralized, then every time I change the strings, I must manually copy/paste the strings into the integration tests, violating DRY. But if they are centralized, it sacrifices readability in the main program. Or there is a better way to do this?

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
Abirafdi Raditya Putra
  • 161
  • 5
  • Possible duplicate of [Why are string resources generally kept external to the code and not inside the code?](http://programmers.stackexchange.com/questions/231870/why-are-string-resources-generally-kept-external-to-the-code-and-not-inside-the) – gnat Aug 04 '16 at 06:08
  • @gnat: not even close. – Doc Brown Aug 04 '16 at 06:54
  • you have to be reading in this question something that I don't see – gnat Aug 04 '16 at 06:55
  • @gnat: the OP obviously knows already "why string resources are generally kept external to the code and not inside the code" (for localization or as he calls it "internationalization") - his question is how to get over the drawback of reduced readability. – Doc Brown Aug 04 '16 at 06:58
  • per my reading question presents storing in code as a viable alternative (and answers in duplicate question explain why it isn't). "it bugs me for days whether should I centralized the strings (make them as variables, so they can be referred by the main program or the tests suite) inside one module or not" – gnat Aug 04 '16 at 07:06
  • @gnat: after thinking twice, I am pretty sure "localization" or internationalization is a red herring - it has actually nothing to do with the problem the OP describes, the problem keeps beeing the same with a non-localized program. – Doc Brown Aug 04 '16 at 11:18
  • @gnat thanks for pointing out the possible answer, sorry my original question is a bit unclear, what really bugs me is that whether should I preserve readability vs centralized strings to prevent DRY in localization tests. DocBrown is actually right, this is not a localization/internationalization problem, I put the internationalization and localization tags because the first tests I wrote are localization tests, and immediately assumed this is belong to i18n and l8n. Should I edit and remove them? – Abirafdi Raditya Putra Aug 04 '16 at 13:13

1 Answers1

3

IMHO the key to solve your problem is how you design your integration tests, and it has probably nothing to do with localization or internationalization at all. In a non-localized program the same problem can occur.

I guess your tests - at least at some level - take some input data, run the program which produces some textual output which contains some of the localized strings. Then, the output is compared to some expected output.

We have a bunch of such programs and tests here, and the way we deal with them is by not hardcoding the output texts directly into the integration tests. Instead, we pipe the output of each test into a file (for example, into a directory "currentOutput" and a file name which identifies the test in a unique manner), compare the file against a pendant in a directory "expectedOutput". When some of the tests fail, we use our favorite diff/merge tool and compare the different files and manually check what causes the difference. When we are sure the difference is only caused by an intended string change, we simply copy the content from "currentOutput" to "expectedOutput" , so updating the expected data is very smooth and painless.

TLDR; duplicate the strings in the tests, but make the updating of strings within the test suite a semi-automatic process.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • 1
    this is a nice solution to preserve readability in main program I guess, sorry I can't upvote you yet. – Abirafdi Raditya Putra Aug 04 '16 at 13:14
  • Nice solution. It guards against unintended changes of literals (yes, they do happen) in a developer friendly manner. Guarding against unintended changes of literals is one of the reasons I sometime do duplicate literals in tests. Usually only for strings used in an API, where unintended changes would cause errors that can be hard to find. Your solution however is much nicer when you are checking formatting, generation and other types of output producing functions. – Marjan Venema Aug 04 '16 at 14:29
  • @user3390639: IIRC upvoting takes 10 rep. You should have enough now :) – Marjan Venema Aug 04 '16 at 14:30
  • @MarjanVenema it takes 15 rep :( – Abirafdi Raditya Putra Aug 04 '16 at 22:11
  • @user3390639: Ah, ok. In that case: ask more questions or answer some :) – Marjan Venema Aug 05 '16 at 08:52