Table of contents
1. Overview of event-driven architecture
2. Overview of event-driven architecture
2. Advantages of event-driven architecture
3. Disadvantages of event-driven architecture
4. General paradigm of event-driven architecture
5. Functions supported by event-driven architecture
3. Quality characteristics of event-driven architecture
4. Event-driven architecture testing strategy
1. Usually use a layered testing strategy for testing
2. Business logic testing strategy for event-driven architecture implementation
1. Main content
1. Overview of event-driven architecture
2. Quality characteristics
3. Testing strategy
2. Overview of event-driven architecture
1. Concept
(1) event
-
Refers to a significant change in state; for example, if there is a hyperlink, placing the mouse on the hyperlink is one state, and clicking the hyperlink is another state;
-
In terms of sources, events can be divided into system internal events and external events;
-
From the type, it can be divided into business events and system events.
(2) Event notification
-
is a special kind of message that notifies other parts of the architecture of events;
-
For example, after a button is clicked, the clicked action needs to be transmitted to other parts to respond, and the special message that transmits the clicked action is called an event notification.
(3) Event-driven architecture
-
Refers to a software architecture that communicates through events, and is one of the most commonly used architectural paradigms; the architecture focuses on the generation, identification, processing, and response of events.
2. Advantages of event-driven architecture
-
Native models the occurrence and processing of events
-
Events, event handling logic, and event handling logic are fully explained
-
Interactive responsiveness is better
3. Disadvantages of event-driven architecture
-
Common problems in asynchronous communication to consider
-
Development is relatively complex, and points related to event handling are also very common
-
At the same time, in practice, failures caused by such defects are often difficult to reproduce and locate
4. General paradigm of event-driven architecture
-
Notification: special messages triggered or triggered by internal and external events are sent to the event queue
-
Event queue (event queue): the entry to receive events and store events at the same time
-
Distributor (event mediator): Distributes different events to different business logic units. It includes two implementation methods: stream processing method or registration publishing processing method (subscription, push).
-
Event channel (event channel): the communication channel between the dispatcher and the processor
-
Event processor (event processor): to implement business logic, after the processing is completed, an event will be sent to trigger the next operation
-
For simple projects, the event queue, distributor and event channel can be integrated into one, and the whole software is divided into two parts: event agent and event processor.
5. Functions supported by event-driven architecture
-
Encoding and decoding of event notifications (optional)
-
Sending and receiving of event notifications
-
Management and maintenance of event queue
-
Registration/deregistration of time
-
Priority of the event (optional)
-
Matching and filtering of events and registration records
-
time broadcast/forward
-
Creation, management and maintenance of event channels (optional)
-
Call method of event handling mechanism
-
Return and/or postprocessing after event handling (optional)
3. Quality characteristics of event-driven architecture
1. Functionality
It is closely related to a specific business domain and has little to do with architecture implementation; however, if the function and architecture are completely separated, it may lead to some defects, such as problems with the logical context of functions, problems with unexpected event handling, and real-time performance. there are also problems
-
functional completeness
-
Basically nothing to do with architecture
-
Event-driven architecture simplifies the implementation of complex interactive responses
-
-
functional correctness
-
Basically nothing to do with architecture
-
Determined by the specific business logic implementation
-
-
functional suitability
-
Architecture independent
-
2. Reliability
-
Encoding and decoding of event notifications
-
Test focus: There is a problem with the encoding and decoding library, and the encoding and decoding buffer overflows;
-
Test methods: decision table, syntax analysis;
-
-
Sending and receiving of event notifications
-
Test concerns: loss of messages, repetition of messages;
-
Test method: scene method;
-
-
Management and maintenance of event queue
-
Test concerns: overflow of the queue;
-
Test method: boundary value analysis;
-
-
Event registration and deregistration
-
Test concern: event repeated registration;
-
Test method: code review;
-
-
Priority of the event (optional)
-
Test focus: Priority inversion; programs generally process high-priority events first, but some high-priority services will depend on some low-priority services, and high-priority services will always be processed, but The situation that cannot be handled according to the expected state;
-
Test methods: scene method, static analysis method;
-
-
Matching and filtering of events and registration records
-
Test focus: There is a problem with the identification of the verification event, and there is a problem with the forwarding logic;
-
Test method: Appropriate code coverage technology is added to the unit test, and related methods such as equivalence classes and decision tables can be considered for the parameters of the notification;
-
-
Broadcasting and Forwarding of Events
-
Test focus: After an exception occurs in event broadcasting and forwarding, all logic that does not appear abnormal will be locked;
-
Test method: static analysis to check;
-
-
Return/post-processing after event processing (optional)
-
Test concerns: undefined processing logic, error return codes, codes that return errors to processing logic, illogical function requirements, time-sensitive situations for dependencies between multiple event processing logics;
-
Scenarios can be used for multiple issues, and static analysis or code review can be considered for testing a single issue.
-
3. Performance efficiency
-
Encoding and decoding of event notifications
-
Test focus: There is a problem with the encoding and decoding library;
-
Test Methods: Equivalence Classes, Boundary Values
-
-
Sending and receiving of event notifications
-
Test concerns: message delay;
-
Test method: boundary value;
-
-
Management and maintenance of event queue
-
Test focus: the event is not processed for a long time;
-
Test methods: scenario method, equivalence class, boundary value;
-
-
Event registration and deregistration
-
Test concern: Not deleted after registration takes up some resources;
-
Test method: scene method;
-
-
Priority of the event (optional)
-
Common problems: incorrect setting of priority, errors in code logic, resulting in untimely event processing or even overflow;
-
Test method: scene method;
-
-
Matching and filtering of events and registration records
-
Test concern: the time does not meet the requirements
-
-
Broadcasting and Forwarding of Events
-
Test focus: Occupies a lot of resources and exceeds the cache capacity of the system
-
Test method: scene method;
-
-
Creation, management and maintenance of event channels (optional)
-
Test method: scene method;
-
-
Call method of event handling mechanism
-
Test focus: cannot meet the requirements of event specificity;
-
Test method: equivalence class method, boundary value method;
-
-
Return and/or postprocessing after event handling (optional)
-
Test focus: the return is relatively slow, and the processing shrinks sharply;
-
Test method: static analysis;
-
4. Ease of use
-
Encoding and decoding of event notifications
-
Test focus: check the legality of the event triggered by the user, and whether the correct error code can be returned when there is an error in the coding specification;
-
Test method: static analysis;
-
-
Sending and receiving of event notifications
-
Test focus: Whether the abnormal data is not protected;
-
Test method: scene method;
-
-
Event registration and deregistration
-
Test concerns: repeated registration, unregistered but received a cancellation request;
-
Test method: scene method;
-
5. Information Security
- Mainly for testing the interface
-
Sending and receiving of event notifications
-
Registration and deregistration of events (subsystems across different regions and network segments)
6. Compatibility
-
Encoding and decoding of event notifications
-
Test focus: Misreading and decoding errors caused by inconsistencies in encoding or decoding logic;
-
Test method: standardized regression test;
-
-
Sending and receiving of event notifications
-
Test concerns: semantic inconsistency;
-
Test method: standard regression test;
-
-
Event registration and deregistration
-
Test concern: registration and cancellation and its content format are inconsistent among multiple subsystems;
-
Test method: standard regression test;
-
-
Priority of the event (optional)
-
Test focus: the priority definition inside and outside the architecture system is different;
-
Test method: scene method;
-
-
Broadcasting and Forwarding of Events
-
Test focus: When events are broadcast and forwarded, there are compatibility issues between systems, and events are forwarded in an unnecessary range;
-
Test method: scene method;
-
7. Maintainability
Under the event-driven architecture, there are generally few maintenance issues (because the software decoupling based on this architecture is already sufficient)
-
Testability
-
Event sending and receiving mechanism
-
intrusion code
-
-
Event queue and dispatcher components
-
extract log
-
-
Event registration/unregistration
-
Function to insert registration module
-
-
Invocation of the event handling mechanism
-
Provide relevant hooks
-
-
8. Portability
-
Under the event-driven architecture, there are generally few portability problems
4. Event-driven architecture testing strategy
1. Usually use a layered testing strategy for testing
(1) unit test
-
each component
-
Event transceiver module/function
-
codec module/function
-
Event queue management module/function
-
Coverage by function and code
(2) Integration testing
-
Designed around core functionality
(3) System test
-
Generally not arranged
2. Business logic testing strategy for event-driven architecture implementation
(1) unit test
-
Focus on event handling logic
(2) Integration testing
-
priority mechanism
-
Integration tests can be skipped
-
The event-driven architecture components that business logic depends on are not tested and integration testing must be completed
(3) System test
-
Specification-Based Testing Techniques
-
Test execution is achieved by using interface or system interface