Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should unmatched error be handled as an assertion error #13

Open
eliasson opened this issue Sep 13, 2019 · 3 comments
Open

Should unmatched error be handled as an assertion error #13

eliasson opened this issue Sep 13, 2019 · 3 comments
Labels
question Further information is requested

Comments

@eliasson
Copy link
Contributor

If a test match on one of Either[L, R] and the other occurs should intent handle that and provide a nice assertion error instead?

Same for all unmatched errors?

@eliasson eliasson added the question Further information is requested label Sep 13, 2019
@provegard
Copy link
Collaborator

Yes I think so

@provegard
Copy link
Collaborator

This is the output when there is a match error:

[info] [FAILED] intent.matchers.ToEqualTest >> toEqual >> lab >> match error (2 ms)
[info]  Test error (C:\kod\projects\dotty-intent\src\test\scala\intent\matchers\ToEqualTest.scala:14:51)
[info]
[info]  scala.MatchError: None (of class scala.None$)
[info]          at intent.matchers.ToEqualTest.$init$$$anonfun$3$$anonfun$2$$anonfun$2(ToEqualTest.scala:14)
[info]          at intent.core.IntentStatelessSyntax.in$$anonfun$1(internal.scala:293)
[info]          at intent.core.IntentStateBase$TestCase.liftedTree2$2(internal.scala:162)
[info]          at intent.core.IntentStateBase$TestCase.run$$anonfun$1(internal.scala:169)
[info]          at scala.concurrent.impl.Promise$Transformation.run(Promise.scala:433)
[info]          at scala.concurrent.BatchingExecutor$AbstractBatch.runN(BatchingExecutor.scala:134)
[info]          at scala.concurrent.BatchingExecutor$AsyncBatch.apply(BatchingExecutor.scala:163)
[info]          at scala.concurrent.BatchingExecutor$AsyncBatch.apply(BatchingExecutor.scala:146)
[info]          at scala.concurrent.BlockContext$.usingBlockContext(BlockContext.scala:107)
[info]          at scala.concurrent.BatchingExecutor$AsyncBatch.run(BatchingExecutor.scala:154)
[info]          at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
[info]          at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
[info]          at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
[info]          at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
[info]          at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
[info]          at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)

Do we want more?

@eliasson
Copy link
Contributor Author

No that is enough for now.

I think I was thinking about adding some sugar to match on either / option / future when I created this issue. Currently the either matchers used in our tests are pretty verbose (although very clear).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants