Task #1220
Updated by Junxiao Shi over 10 years ago
Create skeleton for integrated tests. 1. Create a code repository for integrated tests, with directory for each scenario. # Integrating test 2. Write a scenario integrated test overview.# ## Management tests:## This part tests the basic functionality of NFD and tools that are useful for NFD using ndn-tlv-ping further steps on a single host. This part should include scripts at least the following tasks. These tasks can test the correctness of Forwarder status, Faces, FIB, and Strategy choice. 1. Test nfd-status. This is important since nfd-status is used to set up 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 environment, 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 for these applications is to run both side on the test, cleanup 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 with some tasks above). ## Forwarding tests:## The forwarding tests is going to test how multiple NFD can work together. The following tasks are the environment. very basic tests 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. 2. Test PIT. PIT can be tested using a similar idea from test CS. the difference is that the second consumer should send interest before the data packet get to the forwarder. To test PIT, the application server (producer) has to delay the data packet. 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 can get correct data from correct producer. Also, looping scenario can assume 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 that dependencies, ndn-cpp-dev, associates some prefix to a link to B, 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 are 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 already installed. there in B's PIT. 3. Writing 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 a script in top level directory FIB entry that associates some prefix with TCP/UDP face to execute all (or selected) tests B. Run a producer on B and consumer on A. Collect and verify the result we get from the repository. 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.