Some ideas and tips about NetApp specific tests

Throughout this publication, we will see lessons learned in the design and development of new tests for our NetApps, mainly oriented to NetApp developers and experimenters. Sometimes the creation of new specific tests for our NetApp can be difficult, since we tend to focus on the activity or service that the NetApp performs.

When it comes to proposing infrastructure tests, there are many more concepts that come to mind. These concepts refer to connectivity and the state of that connectivity. For example, a test could be designed to determine, over a specific period, the average latency of the network that we are using for our NetApp. Or if a specific technology is being used, such as 802.11p, checking whether some features of it are working as they should.

An important point when setting up tests for NetApps is to use the same approach that we have just seen. That is, not only to prove that the NetApp does what it should do but also validate everything that surrounds it and is specific to the NetApp itself. Some of these features related to the application would be interesting to turn into tests.

First, one of these most obvious features is the NetApp backend. If the application in any of its parts makes use of a database, it is a good starting point. Now, it would be interesting to design tests related to the use of that database, such as inserts, modifications, deletions and even create large bursts of the previous ones.

Besides, there are the packages and dependencies of our NetApp. It would be necessary to verify through a test that everything needed is installed. It is a very useful and quick way to see if a machine is a candidate to run our NetApp. For example, if we are using a GPS package that is very relevant in our service, we could see if coordinates are generated correctly or if a movement simulation is detected. In this way, we will know that an important part of the application has been tested.

Another aspect to consider is the scope of the NetApp. It is possible to get new points from possible tests if we think about the specific things of the scope of the application. Thinking about the peculiarities of the application opens the doors to testing it. For example, in the case of the vOBU NetApp, it is an application focused on vehicles. In this case, checking that the vehicle’s sensors are collecting information correctly is another idea for a new test. This applies to any hardware element that is related to the functioning of the NetApp.

After all, a service like the one offered by any NetApp is usually divided into multiple elements and steps. It is precisely from these elements and stages that we can get new ideas for test development, not treating the NetApp as a whole but as a division of processes.

It’s important to remember that any aspect of NetApp can be tested since we have the flexibility of Python. Creating the Python code to use as a library for the Robot Framework code makes all existing Python libraries available to the developer.

So, in case you are stuck with how to test a NetApp, remember to extract the particular things from it and also select the hardware elements involved. It is the fastest way to find ideas to test.