Internationalization and Testing

In this chapter, we will internationalize our GUI by displaying text on labels, buttons, tabs, and other widgets, in different languages. We will start simply and then explore how we can prepare our GUI for internationalization at the design level.

We will also localize the GUI, which is slightly different from internationalization.

As these words are long, they have been abbreviated to use the first character of the word, followed by the total number of characters in between the first and last character, followed by the last character of the word. So, internationalization becomes I18N, and localization becomes L10N.

We will also test our GUI code, write unit tests, and explore the value unit tests can provide in our development efforts, which will lead us to the best practice of refactoring our code.

There are no additional Python packages to...

Displaying widget text in different languages

The easiest way to internationalize text strings in Python is by moving them into a separate Python module and then selecting the language to be displayed in our GUI by passing in an argument to this module.

While this approach, according to online search results, is not highly recommended, depending on the specific requirements of the application you are developing, it may still be the most pragmatic and fastest to implement.

Getting ready

We will reuse the Python GUI we created earlier in Chapter 7, Storing Data in Our MySQL Database via Our GUI. We will comment out one line of Python code that creates the MySQL tab because we do not interact with a MySQL database in this chapter...

Changing the entire GUI language all at once

In this recipe, we will change all of the GUI display names, all at once, by refactoring all the previously hardcoded English strings into a separate Python module and then internationalizing those strings.

This recipe shows that it is a good design principle to avoid hardcoding any strings, that our GUI displays, but to separate the GUI code from the text that is displayed by the GUI.

Designing our GUI in a modular way makes internationalizing it much easier.

Getting ready

We will continue to use the GUI from the previous recipe, GUI.py. In that recipe, we had already internationalized the title of the GUI. We will enhance the LanguageResources.py module from the previous recipe...

Localizing the GUI

After the first step of internationalizing our GUI, the next step is to localize it. Why would we wish to do this?

Well, here in the United States of America, we are all cowboys and we live in different time zones.

While we are internationalized to the US, our horses do wake up in different time zones (and do expect to be fed according to their own inner horse time zone schedule).

This is where localization comes in.

Getting ready

We are extending the GUI we developed in the previous recipe by localizing it.

How to do it...

Let's see how to perform...

Preparing the GUI for internationalization

In this recipe, we will prepare our GUI for internationalization by realizing that not all is as easy as could be expected when translating English into foreign languages.

We still have one problem to solve, which is how to properly display non-English Unicode characters from foreign languages.

You might expect that displaying the German ä, ö, and ü Unicode umlaut characters would be handled by Python 3.7 automatically, but this is not the case.

Getting ready

We will continue to use the Python GUI we developed in recent chapters. First, we will change the default language to German in the GUI.py initialization code.

This recipe might be specific to the Eclipse PyDev...

How to design a GUI in an agile fashion

The modern agile software development approach to design and coding came out of the lessons learned by software professionals. This method applies to a GUI as much as to any other code. One of the main keys of agile software development is the continuously applied process of refactoring.

One practical example of how refactoring our code can help us in our software development work is by first implementing some simple functionality using functions.

As our code grows in complexity, we might want to refactor our functions into methods of a class. This approach would enable us to remove global variables and also to be more flexible about where we place the methods inside the class.

While the functionality of our code has not changed, the structure has.

In this process, we code, test, refactor, and then test again. We do this in short cycles...

Do we need to test the GUI code?

Testing our software is an important activity during the coding phase as well as when releasing service packs or bug fixes.

There are different levels of testing. The first level is developer testing, which often starts with the compiler or interpreter not letting us run buggy code, forcing us to test small parts of our code on the level of individual methods.

This is the first level of defense.

A second level of coding defensively is when our source code control system tells us about some conflicts to be resolved and does not let us check our modified code.

This is very useful and absolutely necessary when we work professionally in a team of developers. The source code control system is our friend and points out changes that have been committed to a particular branch or top-of-tree, either by ourselves or by our other developers, and tells us...

Setting debug watches

In modern IDEs, such as the PyDev plugin in Eclipse, or other IDEs such as NetBeans, we can set debug watches to monitor the state of our GUI during the execution of our code.

This is very similar to the Microsoft IDEs of Visual Studio and the more recent versions of Visual Studio .NET.

Setting debug watches is a very convenient way to help our development efforts.

Getting ready

In this recipe, we will reuse the Python GUI we developed in the earlier recipes. We will step through the code we had developed previously, and we will set debug watches.

How to do it...

...

Configuring different debug output levels

In this recipe, we will configure different debug levels, which we can select and change at runtime. This allows us to control how much we want to drill down into our code when debugging our code.

We will create two new Python classes and place both of them in the same module.

We will use four different logging levels and write our debugging output to a log file that we will create. If the logs folder does not exist, we will create it automatically as well.

The name of the log file is the name of the executing script, which is our refactored GUI_Refactored.py. We can also choose other names for our log files by passing in the full path to the initializer of our Logger class.

Getting ready

...

Creating self-testing code using Python's __main__ section

Python comes with a very nice feature that enables each module to self-test. Making use of this feature is a great way of making sure that the changes to our code do not break the existing code and, additionally, the __main__ self-testing section can serve as documentation for how each module works.

After a few months or years, we sometimes forget what our code is doing, so having an explanation written in the code itself is indeed of great benefit.

It is a good idea to always add a self-testing section to every Python module, when possible. It is sometimes not possible but, in most modules, it is possible to do so.

Getting ready

We will extend the previous recipe...

Creating robust GUIs using unit tests

Python comes with a built-in unit testing framework and, in this recipe, we will start using this framework to test our Python GUI code.

Before we start writing unit tests, we want to design our testing strategy. We could easily intermix the unit tests with the code they are testing, but a better strategy is to separate the application code from the unit test code.

PyUnit has been designed according to the principles of all the other xUnit testing frameworks.

Getting ready

We will test the internationalized GUI we created earlier in this chapter.

How to do it...

...

How to write unit tests using the Eclipse PyDev IDE

In the previous recipe, we started using Python's unit testing capabilities, and, in this recipe, we will ensure the quality of our GUI code by using this capability further.

We will unit test our GUI in order to make sure that the internationalized strings our GUI displays are as expected.

In the previous recipe, we encountered some bugs in our unit testing code but, typically, our unit tests will find regression bugs that are caused by modifying the existing application code, not the unit test code. Once we have verified that our unit testing code is correct, we do not usually change it.

Our unit tests also serve as a documentation of what we expect our code to do.

By default, Python's unit tests are executed with a textual unit test runner, and we can run this in the PyDev plugin from within the Eclipse IDE. We can...