Disable prettifying of large objects #2127
Comments
|
@charpov Sorry for replying late, I like your approach, not sure if we should make yet another argument for this, perhaps pass through config map is better, e.g. -Dprettifier.collection.max.size=... and we have a default value of 100. This may be breaking change for other tools that integrate ScalaTest though, so perhaps it is best to be done in 3.3 branch. |
|
I'm glad to hear my code is not too unreasonable. It's only a partial solution, though. For instance, I have tests on large, randomly generated trees (implemented as case classes), that give me the same problem (and I use ScalaTest as a grading system in my teaching, so failed tests are quite common). Defining specific prettifiers is cumbersome, but I can't think of a more generic solution. Systematically truncating the result of |
|
@charpov Fyi I included some improvement for this in the following PR that I just submitted: I agree with you that we can't do much to control the toString, we may try to catch OutOfMemoryError (we are already catching StackOverflowError currently) and make it to return a fixed string like {LARGE_OBJECT}. In general it is not recommended to catch OOME except for resource cleaning purpose, but may be fine since we actually know the the spot that's causing it. What do you think? |
|
I've tried for years to handle OOME in a systematic way (again, because I'm using ScalaTest as a grading system), but it's never worked. I've eventually given up. One issue is that there are many threads involved, and as one thread uses all the memory, other threads start to fail with OOME. Another issue I had is that my tests all have timeouts, and tests that fail with OOME tend to do it slowly and mess up timing anyway, even if I recover from the error. BTW, I see that your code handles |
|
@charpov You're right, I have submitted the following PR to do away with the deprecated GenTraversable and GenMap in Prettifier: Yes OOME will occur in any active thread that is running, like you said it will be impossible to handle the failure in such scenario except cleaning up open resources. It could be of some use if the tests are running in single thread, which is not the usual case most of the time. |
|
I see that you've added a truncating prettifier (thanks!). I'm still facing a difficulty when using custom prettifiers. For instance, in the failed test below, I use a prettifier to shorten the message (I'm truncating the rest of the message, which is huge.) |
|
@charpov Hmm, it seems like the Differ that is producing the 'Analysis' part (diffSet) seems like not take into account of size limit of the passed in Prettifier (the element does not call the passed in Prettifier also): I'll try to see if I can enhance Differ to support that. Cheers. |
This is a feature request. It's a thing that's bitten me many times.
I have a test of the form:
When it fails, I'd be happy with:
Instead, the prettifier tries to build a humongous string and crashes the system with OME.
I'm getting by on a case-by-case with things like:
but it'd be nice to have a more systematic solution. What's the point of generating strings so big no one will ever look at them anyway?
The text was updated successfully, but these errors were encountered: