Best practices for unit/integration test

[Alex Ott <al...@gmail.com>]

Hi all

I was debugging multiple issues over the last day, and I've noticed that
it's very hard to debug asserts like this:

assertEquals(InterpreterResult.Code.SUCCESS, interpreterResult.code());

because it doesn't say what is the reason for it, just a difference. It
would be much simpler to debug if we add the InterpreterResult as a first
argument, so you can see exception, and stacktrace, like this:

assertEquals(interpreterResult.toString(), InterpreterResult.Code.SUCCESS,
interpreterResult.code());

P.S. I maybe can go through most of the tests and fix that - do we need to
have JIRA for such changes?

-- 
With best wishes,                    Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)

Re: Best practices for unit/integration test

[Jeff Zhang <zj...@gmail.com>]

Agree, I also meet such issues before, we may also need to create
utility class for that. e.g. assertSuccess(interpreterResult)



Alex Ott <al...@gmail.com> 于2020年6月10日周三 下午8:17写道：

> Hi all
>
> I was debugging multiple issues over the last day, and I've noticed that
> it's very hard to debug asserts like this:
>
> assertEquals(InterpreterResult.Code.SUCCESS, interpreterResult.code());
>
> because it doesn't say what is the reason for it, just a difference. It
> would be much simpler to debug if we add the InterpreterResult as a first
> argument, so you can see exception, and stacktrace, like this:
>
> assertEquals(interpreterResult.toString(), InterpreterResult.Code.SUCCESS,
> interpreterResult.code());
>
> P.S. I maybe can go through most of the tests and fix that - do we need to
> have JIRA for such changes?
>
> --
> With best wishes,                    Alex Ott
> http://alexott.net/
> Twitter: alexott_en (English), alexott (Russian)
>


-- 
Best Regards

Jeff Zhang