Introducing a JavaScript-based parser and test case generation framework designed for NodeJS-based IoT applications. This innovative solution automates test case creation, ensuring predetermined coverage goals are met. Boosting reliability and efficiency, the framework empowers IoT developers to deliver robust software, tailored to the demands of the IoT landscape.
We've developed purposeful sample codes that mimic real-world scenarios. These codes strategically encompass a wide range of potential paths and routes, mirroring the complexity of actual projects. This approach empowers us to comprehensively evaluate our solution's performance by testing it across a spectrum of situations. Through these samples, we bridge theory and practice, ensuring our approach thrives in the face of real-world intricacies.
In our context, the rule description serves as a map of the data's journey, encompassing both its origin and its designated destinations. Specifically tailored to our setup, these rule descriptors outline the data's inception point, often originating from sensors. Additionally, they meticulously detail the specific routes through which the data must traverse, all the while encompassing crucial parameter information that accompanies it.
Yet, in the realm of lambda coverage and end-to-end coverage, our focus narrows to the intricate pathways the data undertakes. We prioritize the tracking of these destinations and sources to ensure comprehensive coverage. By meticulously maintaining this journey log, we effectively ensure that the data follows the intended paths, enhancing our understanding of the system's functionality and integrity. This meticulous approach guarantees that our coverage assessment accurately captures the entire spectrum of data movement and interaction.
The crux of our approach lies within the EventSource_Mappings. These mappings encapsulate the precise routes taken by a source, charting its trajectory towards a lambda function. Functioning as the point of origination for our code, these mappings allow us to define the inception of our journey. Contained within the EventSource_Mappings are vital elements: the function ARN and the event ARN. These components precisely identify the source and its designated destination. By diligently tracking these elements, we are equipped to unravel the routes that the data traverses.
This serves as the nucleus for both lambda coverage and end-to-end coverage criteria. Starting from a lambda function, we employ a reverse-engineering strategy, effectively retracing our steps through the pathways until we reach the initial sensor. By subsequently inverting this path, we attain a comprehensive test case that aptly fulfills both end-to-end and lambda coverage criteria. In essence, our approach hinges on these EventSource_Mappings, which serve as the architectural backbone that enables us to meticulously dissect the data's journey, thereby achieving a robust and systematic assessment of both coverage dimensions.
The EventBridgeRule_Descriptions file encapsulates pathways that link AWS services together. Acting as the foundational step in the cloud journey, this file lays out the subsequent actions, serving as a guide for data movement. Meanwhile, the EventRule_Map and EventSource_Map play pivotal roles in charting the event's voyage, determining its trajectory, and leading it to the eventual destination—the actuator.
In essence, the EventBridgeRule_Descriptions file forms the bedrock, specifying initial cloud interactions. It's here that we define the first move. Then, the EventRule_Map and EventSource_Map meticulously shape the event's route, navigating it through AWS services, ultimately culminating in the interaction with the actuator. These files collectively orchestrate the intricate dance of data movement, ensuring seamless and orchestrated journeys from source to destination in the AWS environment.
Lambda functions play a key role in determining the destinations once a certain point is reached. These functions serve as the focal points for directing data flows. However, a challenge arises as these files lack internal cues to identify the originating lambda for each destination.
To address this, we've introduced a systematic approach. We've placed explicit comments within each file, facilitating tracking of the corresponding lambda function. By doing so, we establish a clear link between files and their originating lambdas. To ensure seamless execution of our code, please integrate these modifications into your lambda files. This strategic enhancement will enable us to accurately determine the source of destinations, thus optimizing the overall data flow within the system.
The sensor files stand as representations of actual sensor data, serving as the content published to the cloud. In our setup, we've designated three distinct devices, each recognized as a sensor. It's important to emphasize that each sensor is aligned with a specific topic, ensuring a focused channel for data publication to the cloud.
Further, the device-data file encapsulates a comprehensive amalgamation of topics alongside their corresponding attribute-value pairs. This consolidated file presents an organized overview of the collective sensor information.
Employing the wealth of codes and data we've meticulously generated, our strategy has evolved into the creation of individualized tables for each integral file. This approach is laying a solid foundation for the eventual seamless integration of our entire framework.
-
At the core, we find the sensor info list is a repository meticulously detailing the devices. With precision, it documents each device's assigned topics along with the corresponding attribute-value pairs within those specific topics.
-
Moving forward, the TRD table serves as the vault for our rule structures. Within it, an extensive collection of rules is paired with their corresponding SQL queries and the destinations they dictate.
-
Parallelly, the ESM table captures the pivotal dynamics of event sources and their designated lambda destinations. Here, the blueprint of data journeys is meticulously laid out.
-
The ERD table is a key map of service relationships, meticulously tracing the pathways between sources and destinations, painting a vivid picture of interaction networks.
-
The culmination arrives with the RuleData, which harmoniously merges the ESM and TRD tables. This fusion represents a pivotal convergence, forging the road ahead by interweaving event sources, destinations, rules, and SQL queries.
In this strategy, each table contributes a unique layer. As they come together, they form a comprehensive tapestry poised to navigate complexities, ensuring the seamless orchestration of data flow within our framework.
Our focus now shifts to our main goal: creating lambda coverage and end-to-end coverage paths. These paths are pivotal test cases that validate our solution's effectiveness. By meticulously navigating through sources, rules, destinations, and event sources using our organized tables, we ensure comprehensive coverage. These tests exemplify real-world data movement, demonstrating our solution's reliability and efficiency.
By leveraging the Sensor data list and the integrated Rule Data table, we can seamlessly chart a course from a sensor to its corresponding lambda, effectively achieving lambda coverage. The Rule Data table, born from the fusion of the TRD and ESM tables, is the cornerstone, providing the intricate roadmap of rules and destinations.
The synergy between the Sensor data list and the integrated Rule Data table is pivotal. This integration empowers us to follow the data's journey through the system, from its origin as sensor data to its ultimate destination at the lambda function. By joining these components, we successfully capture the data flow through the intricate pathways we've outlined. This process culminates in a comprehensive representation of lambda coverage.
Require:
Require:
Ensure: Table of test requirements for Lambda coverage
Initialize Table
for each Lambda function
if
Mark
TriggerInfo of
Update
Call Parser to get Core_data with TriggerInfo of
else
if
Mark
Execute Procedure to find Invoker’s Invoker (
Update
else
Querying logs of
Update
end if
end if
end for
Procedure to find Invoker’s Invoker (
for each
if
if
Mark
TriggerInfo of
update
Call Parser to get Core_data,
else
if
Mark
$II$ =
Querying logs of
else
if
Mark
Querying logs of
end if
update
end if
end if
end if
end for
return
repeat Procedure To find Invoker’s Invoker
until
End-to-end coverage serves as an extension of lambda coverage, encompassing the entire journey from the lambda function to the final actuator. In this process, we leverage the lambda to destination files to guide our path. Starting from the lambda, we progress step by step, assessing each transition.
When we encounter an actuator, our objective is met. However, if we encounter a service, we consult the ERD table to uncover the route to the actuator. For example, if we come across an SNS service, the ERD table guides us to the actuator.
This meticulous navigation ensures that we explore every aspect of the data's journey, from its origin as sensor data to its ultimate interaction with the actuator. Through this comprehensive approach, we establish a holistic view of data movement, affirming the thoroughness and effectiveness of our solution.
Require:
Ensure:
Initialize End-to-End Flow Table TEE with columns LambdaName, LS, Params
Invoke Algorithm 1 ▷ Return
for Each LambdaName
if
Mark
Params
update
else
if
Params
update
invoke Procedure to find successor’s successor(
else
if
Rerun algorithm of EEFC generation for
else
extract the params by querying logs of
update
end if
end if
end if
end for
Procedure to find successor’s successor(
for each
if
if
update
Rerun algorithm of EEFC generation
end if
else
if
Params = Querying logs,
Rerun Procedure to find
update
end if
end if
end for
return
for each
if (
get its deviceName from (
end if
end for
Require:
Initialize
if
EventGenerator(EG) == Sensor & EventConsumer(EC) == IoTCore
for every
Extract deviceName
EGName =
ECName =
Event =
Append the entry to
end for
else if
EG == IoTCore & EC == AWS Service or Lambda Function
for every
Extract ActionDestination, SQLQuery from
EGName =
ECName =
Event =
Append the entry to
end for
else if
EG == Lambda Function & EC == AWS Service or Lambda Function
for every
Extract target service, paramsSent from
EGName =
ECName =
Event =
Append the entry to
end for
else if choice == 4 then
EG == AWS Service & EC == Lambda Function
for every EventSource in
Extract EventDestination(
Extract paramGot to EventDestination from
EGName =
ECName =
Event =
Append the entry to
end for
else
EG == AWS Service & EC == AWS Service
for every EventSource in
Extract
Event =
Append the entry to
end for
end if
Merge tuples on common
return