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?

  • @gnat: not even close. – Doc Brown Aug 4 '16 at 6:54
  • you have to be reading in this question something that I don't see – gnat Aug 4 '16 at 6: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 4 '16 at 6: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 4 '16 at 7:06
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.

  • 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 4 '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 4 '16 at 14:29
  • @user3390639: IIRC upvoting takes 10 rep. You should have enough now :) – Marjan Venema Aug 4 '16 at 14:30
  • @MarjanVenema it takes 15 rep :( – Abirafdi Raditya Putra Aug 4 '16 at 22:11
  • @user3390639: Ah, ok. In that case: ask more questions or answer some :) – Marjan Venema Aug 5 '16 at 8:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.