![]() It actually had an entirely different name, too: Viva64. In the beginning, the PVS-Studio analyzer was an application for detecting bugs specific to the porting of C/C++ code to 64-bit platforms. Build/installation/deployment correctness tests.External tests for command-line applications.Tests for specific features (such as tracking compiler launches, etc.).Analysis quality tests (for the C/C++/C#/Java modules), which check a large pool of test projects on various operating systems (Windows, Linux, macOS) and compare the logs of new warnings with the reference ones.We don't have many unit tests, though, but they are complemented by lots of other test systems: The number of automated GUI tests (45) makes about one tenth of the total number of tests for PVS-Studio. I'd like to note that at present, our test system meets most of the recommendations. Even a slight change in the UI may break lots of tests and force you to fix them. Besides, UI tests are extremely costly not only at the development phase but also at all the next phases of the application life cycle. With all these factors combined, programmers will typically content with a one-time manual test run for a new feature rather than build UI tests. To generate good automated UI tests without (or with little) programmer assistance, you need commercial software tools. This all has little to do with the application code, so developers don't take on this job willingly. Besides, it's not always easy to choose the right person to assign the task of building these tests to since they are supposed to simulate user actions. You don't want to have many of them as they are difficult to create and take quite a while to complete. Opposed to them, at the top of the pyramid, are automated UI tests. ![]() ![]() Indeed, they are easier to make at the development phase and take very little time to complete. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |