PersistentEntityTestDriver improvements
See original GitHub issueTests based on PersistentEntityTestDriver
present some repetitive idioms like:
- asserting there’s no serialization issues
- asserting every command handler sends a reply
Writing the tests in Java using JUnit there’s a common snippet in an @After
method.
Writing tests in Scala (using scalatest) has similar code duplication. In scalatest-based tests in particular Lagom’s testkit could provide ScalaTest fixture traits to remove the duplication and provide default assertions.
Credit: inspired by scalatestplus-play
Issue Analytics
- State:
- Created 5 years ago
- Comments:7 (5 by maintainers)
Top Results From Across the Web
Persistent Entity (classic) - Lagom Framework
A PersistentEntity has a stable entity identifier, with which it can be accessed from the service implementation or other places. The state of...
Read more >lagom模板帮助文档 - CSDN
单元测试的实体可以使用PersistentEntityTestDriver,将不使用一个数据库的情况下 ... 1000- Rainbow: Rainbow: Combining Improvements in Deep Reinforcement ...
Read more >Untitled
Previous issue PersistentEntityTestDriver improvements. Although the ultimate solution would be not to have any conflicts between Vue.
Read more >Java PSequence類代碼示例- 純淨天空
INSTANCE; PersistentEntityTestDriver<BasketCommand, PEBasketEvent, ... That can be improved by implementing a smarter // merge that takes the timestamps ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Sorry, didn’t check the PR first. Looks like your implementation is very much like mine except throwing an exception instead of using test framework specific checks. And nothing is stopping a user from extending your trait into something more test framework specific if one wanted to do so.
@PerWiklander There’s an open PR; the issue is that we don’t want to marry this to scalatest, so we can’t depend on those mixins. See the linked PR.