GRPC Unit Tests: NetworkLinkService Implementation

Implementing robust unit tests is crucial for ensuring the reliability and correctness of any software system. This article delves into the process of adding gRPC unit tests for the NetworkLinkService within the Cizor project's spacetime-constellation-sim repository. This detailed guide will walk you through the steps involved, from setting up the testing environment to validating various link operations and endpoint configurations. By the end, you'll understand how to effectively test gRPC services and ensure they function as expected.

Setting Up the Testing Environment

The foundation of any good testing strategy is a well-prepared environment. For our NetworkLinkService gRPC unit tests, we need to establish a controlled and predictable setting. This involves setting up in-memory components and pre-creating necessary entities. The initial setup is paramount to ensure our tests run smoothly and provide accurate results. The testing environment should mirror the production environment as closely as possible, without the complexities and overhead. We aim to create a sandboxed environment where we can manipulate the state and interactions without affecting other parts of the system or external services.

In-Memory Components: ScenarioState, Scope 1, and Scope 2 KBs

To isolate our tests and avoid dependencies on external systems, we'll use in-memory components. Specifically, we'll create an in-memory ScenarioState along with in-memory Scope 1 and Scope 2 Knowledge Bases (KBs). These in-memory components allow us to simulate the system's state and data storage without relying on actual databases or persistent storage. This approach makes our tests faster, more reliable, and easier to set up and tear down. The in-memory ScenarioState serves as a container for the simulation's state, while the Scope 1 and Scope 2 KBs hold information about the network topology and link configurations, respectively. By using in-memory KBs, we can easily manipulate the data and verify that our service correctly interacts with the data layer.

Pre-Creating Nodes and Interfaces

Before we can test the creation of network links, we need to have nodes and interfaces in our simulated environment. We'll pre-create a couple of nodes and interfaces, both wired and wireless, using the ScenarioState or the NBI (Northbound Interface) node service. This step ensures that we have the necessary entities to establish links between. The pre-creation of nodes and interfaces is a critical step, as it sets the stage for testing link creation and management. Wired interfaces represent physical connections like fiber optic cables, while wireless interfaces represent connections like Wi-Fi or satellite links. By having both types, we can test different scenarios and ensure our service handles them correctly. The NBI node service provides a way to programmatically create and manage nodes and interfaces, making it a convenient tool for setting up our test environment.

Direct Service Method Invocation vs. In-Process gRPC Server

When testing gRPC services, we have two primary options for invoking the service methods: direct service method invocation and using an in-process gRPC server. Direct service method invocation involves calling the service methods directly in our test code, bypassing the gRPC layer. This approach is faster and simpler, as it avoids the overhead of gRPC serialization and deserialization. However, it doesn't fully test the gRPC layer itself. An in-process gRPC server, on the other hand, starts a gRPC server within our test process, allowing us to make gRPC calls to the service as if it were running in a separate process. This approach provides a more complete test of the gRPC layer but adds some complexity and overhead. For our unit tests, we can choose either approach depending on the specific requirements and trade-offs.

Test Cases for NetworkLinkService

With the testing environment set up, we can now define specific test cases to validate the behavior of the NetworkLinkService. These test cases should cover various scenarios, including creating valid links, handling invalid endpoints, and managing links through CRUD (Create, Read, Update, Delete) operations. Each test case should focus on a specific aspect of the service's functionality, ensuring that it behaves as expected under different conditions. A well-designed test suite provides confidence in the service's correctness and helps identify potential issues early in the development process. We'll focus on key aspects such as static terrestrial wired links, invalid endpoints, wireless link validation, and CRUD operations to provide a comprehensive evaluation.

Static Terrestrial Wired Link

Our first test case involves creating a static terrestrial wired link between two wired interfaces. This scenario represents a common type of network connection, such as a fiber optic cable between two routers. The goal is to verify that the CreateLink method correctly creates a link with the expected endpoints and that the link is stored in the ScenarioState and Scope 2 KB. Additionally, we need to check if the link is marked as