Building Virtual Communications

Goal

In our pursuit of optimizing automated testing processes, I built a solution that enables the display of SMS and email directly in a web browser. This aims to empower our automated test team by facilitating the creation of scripts for triggers and content checking without the need to send actual communications, thus eliminating associated costs

How Did We Achieve It?

To implement this functionality, we created a SvelteKit application with three distinct paths: printer, sms, email.

Setting Up the SvelteKit Application

First, we initialized a new SvelteKit project and set up the necessary routes. Each path corresponds to a specific communication method, and each has its own API endpoint that accepts POST requests.

1. Printer Path:
   • The printer path simulates sending a document to a printer. The API endpoint for this path receives the print job details via a POST request, saves the job data, and then displays the job in the frontend interface.
2. SMS Path:
   • The SMS path handles sending text messages. Similar to the printer path, the API endpoint here accepts a POST request containing the message details, stores the message data, and shows it in the frontend.
3. Email Path:
   • The email path is designed to handle sending emails. The API endpoint accepts email details through a POST request, saves the email information, and displays it in the frontend.

Each of these paths ensures that the data received is properly handled and displayed to the user.

Handling Requests

Our application sends requests from various workers. These workers need to know whether to use virtual communication methods or real ones. This decision is based on the settings configured in our backoffice.

Toggling Communication Preferences

In the backoffice, we have a feature that allows us to toggle our communication preferences between virtual and real communication methods. Here's how it works:

1. User Preference Storage:

   • Users can set their preferences for communication (virtual or real) in the backoffice interface. These preferences are stored in our database.

2. Fetching Preferences:

   • When a worker sends a communication request, the application first fetches the user's communication preference from the database.

3. Decision Making:

   • Based on the fetched preference, the application decides whether to use virtual communication (for testing and development) or real communication (for actual production use).

4. Bifurcation Logic:

   • The fetched preference creates a bifurcation in the communication process. If the preference is set to virtual, the application uses mock services to simulate the communication. If set to real, it uses actual services to perform the communication.

Benefits

Browser Integration:

• Implement a system that seamlessly integrates with web browsers, allowing for the real-time display of SMS, Email, and Printer content within the browser interface.
• Ensure compatibility across popular browsers to accommodate diverse testing environments.

Cost-Efficient Testing:

• Reduce testing expenses by eliminating the need for actual communication transmission during the testing phase.
• Ensure that the browser-based display accurately reflects the behavior of SMS, Email, and Printer outputs without incurring real-world costs.