Changes for page Testing in eMagiz

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -15,18 +15,21 @@
15	15	* End-To-End Testing
16	16
17	17	== 3. Testing in eMagiz ==
18		-
	18	+
19	19	This fundamental will zoom in on the testing functionality incorperated within the eMagiz portal. We will focus on different aspects of testing which can be executed at different moments within the development in your integrations. We cover four different types of testing which are part of software testing in general and explain them on a conceptual level. For each test we also discuss how those are integrated within the portal and where to find further explanation on applying those test within eMagiz.
20	20
21		-=== 3.1 Unit Testing ===
	21	+=== 3.1 Queue Statistics ===
22	22
23		-Unit testing is a common practice within software platforms. Usually, unit tests are performed by developers during development. It entails testing individual integrations or the components within an integration, such as transformations or mappings. The unit test aims to test early within the development process to identify and fix issues early before they become more difficult and costly to find and solve.
	23	+In the Manage phase of eMagiz, we collect statistics to determine whether a message has been sent from one system to another. For example, we have the queue statistics for messaging and API Gateway. In this overview, you can zoom in on a specific queue and see the number of messages sent within that timeframe, the number of messages in the queue at a particular time, and whether or not messages are consumed at a specific moment in time. See below for an illustration of this concept.
24	24
25		-Within eMagiz, we have a dedicated unit testing functionality called "flow testing." One of the key benefits of flow testing is that your integration does not have to be deployed. Therefore, findings can be easily implemented during development. eMagiz supports certain components' live testing to test communication with external systems. More information on flow tests can be found in the following microlearnings:
	25	+[[image:Main.Images.Fundamental.WebHome@fundamental-traceability-in-emagiz--queue-statistics.png]]
26	26
27		-* [Crashcourse Platfrom>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform||target="blank"]]
28		-* Regression testing
	27	+With the help of this overview, you can determine that a queue has processed a message at a specific moment. However, the statistics do not tell you anything about the content of the data. For most use cases, this is sufficient as the fact that a message has been sent is proof that the receiving application has received the data and can be found in that application.
29	29
	29	+For more information on queue statistics please check out the following [[Crashcourse Messaging>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Messaging.crashcourse-messaging-interpreting-queue-statistics||target="blank"]]
	30	+
	31	+In some cases, however, more traceability is needed for Ops work. For those use cases, we have additional functionality within eMagiz called data sink.
	32	+
30	30	=== 3.2 Data Sink ===
31	31
32	32	On top of the standard Manage functionality in eMagiz, you can acquire additional functionality that allows you to sink data at any given point in the flow into a bucket hosted by eMagiz. We advise you to do this twice per integration. Once when the message enters the eMagiz platform and once the message leaves the eMagiz platform. By providing a unique identifier (i.e., an order number), you can search through this data for maximum 180 days (minimum 30 days) to determine whether a specific message with a particular identifier is indeed received and/or delivered by eMagiz in the Manage phase of eMagiz. See below for an illustration of this functionality.