Skip to content

Commit 9bea504

Browse files
committed
refine screenshots
1 parent 3d291c7 commit 9bea504

File tree

5 files changed

+4
-2
lines changed

5 files changed

+4
-2
lines changed

_docs/en/ace-integration-unit-testing.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ The message flow under test (Flow1) has an MQ Input node to receive input messag
1616

1717
The output queue is a 'joint' queue as there is a downstream message flow (Flow2) listening to it, like shown below.
1818

19-
![Original Design](../../screenshots/ace/original-design.png)
19+
![Original Design](../../screenshots/ace/original-design.svg)
2020

2121
The primary way to integration unit test Flow1 is to provide input to it and examine its output. Now there is a problem. Before we get a chance, the output message produced by Flow1 is immediately picked up by Flow2, i.e. we won't be able to examine Flow1's output message here.
2222

@@ -29,7 +29,7 @@ A critical thing to do for ACE integration unit testing is to `isolate the messa
2929

3030
Approach 1 is my favorite as it is simple.
3131

32-
![New Design](../../screenshots/ace/new-design.png)
32+
![New Design](../../screenshots/ace/new-design.svg)
3333

3434
Notice that the isolation is only needed in integration unit testing environment. Other environment such as ST (System Testing) or SIT (System Integration Testing) environment may not need it as the testing scope or strategy is different. On the other hand, configuring a message flow or queue differently in different environments is quite common in ACE project.
3535

screenshots/ace/new-design.png

-23 KB
Binary file not shown.

screenshots/ace/new-design.svg

Lines changed: 1 addition & 0 deletions
Loading
-7.24 KB
Binary file not shown.

screenshots/ace/original-design.svg

Lines changed: 1 addition & 0 deletions
Loading

0 commit comments

Comments
 (0)