The article was published on Engineers Edge.
Even though Linux has a relatively small percentage of desktop users, that small percentage must be provided with well-developed and tested software. That means testers all over the world should be ready to fulfill any customer whim, including testing Linux-based applications. This is where the following tutorial comes in – to help prepare for this scenario.
The Great Battle of Linux and Windows
Unlike the majority of operating systems, Linux is a free one. It does not require any license to purchase it and can be downloaded at no charge. A lot of available software is developed for Linux, so a user doesn’t experience any inconvenience when choosing Linux over Microsoft.
The main difference between Linux and Windows is the superior flexibility Linux provides. While Windows has the same settings for all users, Linux settings and configurations can be easily adjusted to fit each user’s preferences. This is why every user has a unique system, which can’t be said about Windows. It is these standard Windows settings that most PCs have that make Microsoft PCs more vulnerable than Linux systems.
Being a stable system, Linux is also well-known for its extremely high security. Despite many attempts hackers have made to break the system, Linux has managed to remain secure.
Another important Linux characteristic is the productivity it supports. If you run two identical programs on two identical computers with the only difference being the OS (Windows or Linux), you’ll find the Linux OS operates faster. Consider the statistics; more than 95 percent of supercomputers are operated by *nix, and a significant number of servers are run on Linux distributions.
Linux Standard Base (LSB) Testing
Unlike Microsoft, Linux doesn’t have hundreds of hired developers and quality engineers to maintain the quality of software produced for its users. Regardless, the community of Linux volunteers has found a way to underpin long-term compatibility guarantees and comprehensive compatibility testing.
Together, the Linux Foundation and the Institute for System Programming of the Russian Academy of Sciences are putting huge resources toward developing new tools and technologies to break through LSB testing challenges. These resources, known collectively as the LSB Testing Framework, include such components as Linux Application Checker, Distribution Testkit (DTK) Manager, AZOV Shallow Test Development Framework, T2C Normal Test Development Framework and UniTESK Deep Test Development Framework.
Also, a great number of paid-for tools are developed for testing software that runs Linux distributions. Now we can move on to the technical differences testers should be aware of when it comes to Linux.
Introduction to *nix
To distinguish between two operating systems we’d like to share some hints to help avoid their specific singularities. We suggest every novice Linux user start with the “isman” command, which displays online manual pages for specified commands. If you put “man ls,” for instance, this will return info regarding the command you may want to learn: Name, Synopsis, Description, Options.
Pay attention to the fact that command names, paths and file names are case-sensitive. For example, “test.log” and “TEST.log” could be different files in the same directory.
Spaces were originally used for pointing multiple arguments of the command, so if you use them in file names within the terminal (console), that will cause incorrect behavior. Therefore, you should use underscore or CamelCase (PascalCase) instead (e.g. “test_log” or “testLog” instead of “test log”).
The “mv” command should be used if you need to rename a file: mv test.tar.gz temptest.tar.gz. That will change the name of “test.tar.gz” to “temptest.tar.gz.”
Overwritten or modified files couldn’t be restored to their original state in Linux, since this OS doesn’t have an “undo” function. The same thing happens if you need to restore a file that was deleted earlier. Linux has neither a “Trash” nor “Recycle” bin. Moreover, you have no chance to restore deleted files and folder using standard tools in most Unix distributions. This is why you should be careful when working with Linux. You have to make sure you delete files you really don’t need; specify unique parameters for the rm command. For example: rm -i test*.txt (user will be prompted). Finally, the alias command will help to reconfigure the rm command call if you really care about data loss (which most of us do).
You should always keep in mind shortcuts: current directory (.) and parent directory (..). Never miss them and do not run: rm -r .* This command will delete the parent directory (the expression matches “..”).
Be aware of the autocomplete function for command or file names if you work within a console: type a few first characters of the name and press the Tab key.
If you need access to recent command history, you can use up and down arrows on the keyboard to browse commands you previously ran.
What are the limits?
Next, let’s explore path types as well as name length limitations in the *nix OS. It’s best to start with common terms.
There are two types of paths: absolute and relative. An absolute path is the location of a file or directory from the root directory (top level): e.g. /var/log/protocol/log. Relative path means path related to the current directory (pwd). For example, you are located in /var/log and you want to go to the directory /var/log/protocol/log/. You can use relative path here, so apply: cd protocol/log/.
As for limitations applied to folder and file names in *nix, there are 256 characters for a name and 1,024 characters for an absolute path (these limitations should also be checked during the test of your web application).
When working on Linux, you cannot log in as the root user (technically, the top level user or administrator), which is either prohibited or impossible due to an unknown or hidden password used as part of the security policy. At the same time, most of daily routine administrative tasks require administrator permissions: web app start/stop, database restarting/cleaning, new build deployments and so on.
To complete those tasks, you have another solution: use sudo commands (requires a password as well – stands for super user do). Just use sudo followed by the required command to perform activities with so-called super user permissions: sudo apt-get install shellutilities.
In the next part of the article we`ll continue discussing testing specifics of Linux OS.