fix: not.toHaveLog no longer returns a false pass when waiting for Cl…

[danemauland]

Calling expect(options).not.toHaveLog(expectedLog) when the logs contain expectedLog would incorrectly pass. This happens when logs generated previously in the tests don't propagate to CloudWatch in time for the toHaveLog matcher to catch it.

To fix this, I added a new util, wrapWithRetryUntilPass, that will continue to query until the log is found or until the test times out.

[coveralls]

Pull Request Test Coverage Report for Build 2111831727

• 0 of 11 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.005%) to 99.73%

---

Totals
Change from base Build 2086947220:	0.005%
Covered Lines:	615
Relevant Lines:	615

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 3297002803

• 11 of 11 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.005%) to 99.731%

---

Totals
Change from base Build 3296984775:	0.005%
Covered Lines:	617
Relevant Lines:	617

---

💛 - Coveralls

[AlessandroVol23]

I've got exactly that issue.
I test my EventBridge integration and there are normally two common patterns:

flag: true -> EB should consume event

flag: false -> EB shouldn't get event

It would be nice to test both. But every time I use expect().not.toHaveLog() it passes.

[erezrokah]

Thanks for the PR @danemauland and sorry for the late reply.
Two comments:

1. I think we should add the same logic for the Chai integration, WDYT?
2. Handling the negated logic (toNot) is a bit tricky. With this PR passing tests will always wait the full timeout correct? I guess it's better than to pass on failures 🙃

How long does it usually take the logs to arrive? Maybe we can adjust the default time accordingly for negated tests