Task #1220
Updated by Yi Huang over 10 years ago
# Integrating test overview.# ## Management tests:## This part tests the basic functionality of NFD and tools that are useful Create skeleton for further steps on a single host. This part should include at least the following tasks. These tasks can test the correctness of Forwarder status, Faces, FIB, and Strategy choice. integrated tests. 1. Test nfd-status. This is important since nfd-status is used to observe NFD behavior, we should make sure nfd-status works correctly. The basic step we could think of to test nfd-status is to freshly start an NFD and run nfd-status then see whether it produces the expected result. 2. Test NRD. The steps to test NRD is to start an application server (such as ndn-traffic-server) with "NRD=1" and then use nfd-status to verify the change of FIB. 3. Test nfdc. The idea to test nfdc is similar. Run nfdc with different features and use nfd-status to observe the change of NFD. 4. Test other applications. We are using different applications such as peek/poke/ndn-tlv-ping/ndn-traffic-generator in the integrating tests. These applications need to be tested as well. The very basic test Create a code repository for these applications is to run both side on the same host and see whether they works. 5. Test local face. On one single host, run both producer and consumer and see whether NFD can forward those correctly (might be duplicated integrated tests, with some tasks above). ## Forwarding tests:## The forwarding tests is going to test how multiple NFD can work together. The following tasks are the very basic tests directory for CS, PIT, FIB, and Strategy. 1. Test CS. The very basic test for CS is to have one producer and two consumers on the same host. One consumer sends an interest. After the consumer gets data, we let the second consumer to send an interest requesting the same data. Verify the second consumer gets the data but the producer does not see the second interest. We also need to test features of CS. For example, does CS behave exactly as expected when there are too many content objects, when the interest has different selectors (mustbefresh, max/min suffix, etc.). After that, we should then test CS on different topologies. each scenario. 2. Test PIT. PIT can be tested Write a scenario using ndn-tlv-ping on a similar idea from test CS. the difference is that the second consumer single host. This should send interest before the data packet get include scripts to set up the forwarder. To test PIT, environment, run the application server (producer) has to delay test, cleanup the data packet. environment. This feature might need to be implemented. 3. Test FIB. For FIB, we have to test its longest match feature. The very basic way to test FIB is to have different producers to populate FIB entries and verify whether the client scenario can get correct data from correct producer. Also, looping scenario needs to be tested. To test looping scenario, we should have two hosts A and B. And there are two cases. The first case is, A has a FIB entry assume that associates some prefix to a link to B, dependencies, ndn-cpp-dev, and B has a FIB entry that associates the same prefix to the same link to A. If one client on A send an interest with that particular name, the interest should be dropped at B since NFD shouldn't send the interest back with the same link. The second case should be A has a FIB entry that associates some prefix to a link to B and B has a FIB entry that associates with the same prefix to another link to A. In this case, A receives the interest from one face and forward it to the other face. Once B see the interest again, B should drop the interest since it is are already there in B's PIT. installed 4. Test Strategy. The test of strategy includes flooding and NCC. For both strategy, create topologies (link failure, etc.) to test whether the interest goes as expected. 5. Test TCP/UDP faces. Create two hosts A and B. Then use nfdc to add 3. Writing a FIB entry that associates some prefix with TCP/UDP face script in top level directory to B. Run a producer on B and consumer on A. Collect and verify the result we get execute all (or selected) tests from the client. 6. Test multicast. Create three VMs A, B, and C within the same subnet. On B and C, start producer. Then on host A, use nfdc to associate some prefix to multicast face, then start a consumer to send the interest. Try this with B and C serves different prefix and same prefix. 7. Test /localhop. Create three VMs A, B, and C with connection like A-B-C. On B and C, start producer that serves /localhop/someprefix. Then on A, start a consumer to send the prefix. the consumer should only get data from B but not C. Also try to turn off the producer on B, then consumer on A should not receive any data even C has a producer serving that prefix. 8. Test /localhost. In this part, the test should test whether the interest with name /localhost/someprefix can go outside the local NFD and whether the interest from outside local NFD with name /localhost/someprefix can reach the producer serving the same prefix. Currently I cannot think of a way to test this since I don't know whether there is a way to produce an interest with name /localhost/someprefix and let it to go to a remote NFD. repository.