~sircmpwn/hare-users

1

Re: `assert(condition, error_msg)` only accept string literal as `error_msg`?

Details
Message ID
<D6OUCGWSAZCF.2ZEGLXYJK97DX@cmpwn.com>
DKIM signature
pass
Download raw message
On Mon Dec 30, 2024 at 12:04 AM CET, Ye Wison wrote:
> That’s what I did so far, but the problem of “fmt::println” is that it
> messes up the whole test output results, as I have to print a lot to
> figured out what’s wrong, I end up with scroll up a few seconds in
> terminal to see the “hare test” result (which line fails), that’s quit
> inconvenience and it happens a lot during the dev process….:)
>
> I’m hoping “hare test” somehow print the backtrace, that solves the
> problem perfectly:-)

Gotcha. As it so happens, I have a patch up on the mailing list which
prints the backtrace for failed tests :)

It would also make sense IMO to truncate long test logs.

Re: `assert(condition, error_msg)` only accept string literal as `error_msg`?

Details
Message ID
<CADC8Pp6E-a59zFemfVy=hBzEw-T02CTjL6s1eqB3g79f_SwG+Q@mail.gmail.com>
In-Reply-To
<D6OUCGWSAZCF.2ZEGLXYJK97DX@cmpwn.com> (view parent)
DKIM signature
pass
Download raw message
Actually, maybe simply swapping the `hare test` output and
`fmt::println` would be an easy fix/improvement?

Let's me show you my case:

When I run `hare test`, I got the following output:

```bash
Running 50/50 tests:

ucp::create_body_payload_should_work.............................PASS
in 0.000012060s
ucp::create_body_payload_should_fail.............................PASS
in 0.000175381s
ucp::ucp_command_to_byte_should_work.............................PASS
in 0.000004265s
ucp::ucp_command_from_byte_should_work...........................PASS
in 0.000004306s
ucp::basic_encryption_impl_should_fail_with_different_keys.......PASS
in 0.000161823s
ucp::basic_encryption_impl_should_work...........................PASS
in 0.000146079s
ucp::algorithm_type_to_byte_should_work..........................PASS
in 0.000017134s
ucp::algorightm_type_from_byte_should_work.......................PASS
in 0.000003646s
frame::decode_frame_should_fail..................................PASS
in 0.000222516s
frame::encode_basic_encryption_should_work.......................PASS
in 0.000384216s
frame::encode_should_work........................................PASS
in 0.000272230s
frame::encode_should_fail........................................PASS
in 0.000014132s
frame::decode_a_single_frame_with_basic_encryption_should_work...FAIL
in 0.000557161s
frame::decode_a_single_frame_should_work.........................PASS
in 0.000551885s
frame::decode_frame_slice_with_invalid_frames_should_work........PASS
in 0.001136640s
frame::decode_frame_slice_should_work............................PASS
in 0.001206330s

.... ignore the rest


Failures:
frame::decode_a_single_frame_with_basic_encryption_should_work:
frame/+test/decode_single_frame_test.ha:65:31: assertion failed

.... ignore the rest


//
// `fmt::println` starts after the `hare test` result!!!
//

(D) [ ucp::Frame - debug_print ] {
        command: ProjectDataResponse
        algorithm: BasicEncryption
        //
        // Complex nested struct debug print here, a lot of lines
        //
        frame_bytes:
FAF2BB04AABBCCDD14009E7467773B1E011257011E131218571E04571819CAFB

.... ignore the rest


// Summary at the bottom
15 passed; 1 failed; 16 completed in 0.004869804s
```

So, the thing that doesn't help fast debugging is that:

I have to scroll up around 150 lines to see the `Failures:` info
(which file, which line) and scroll down to the bottom again to see
the extra debug print before I can figure out what's wrong:)

If swap the order of `hare test` output and `fmt::println` like this,
that would be super helpful:


```bash
//
// `fmt::println` goes first
//

(D) [ ucp::Frame - debug_print ] {
        command: ProjectDataResponse
        algorithm: BasicEncryption
        //
        // Complex nested struct debug print here, a few lines per Frame
        //
        frame_bytes:
FAF2BB04AABBCCDD14009E7467773B1E011257011E131218571E04571819CAFB

//
// `hare test` output follow
//
Running 50/50 tests:

ucp::create_body_payload_should_work.............................PASS
in 0.000012060s
ucp::create_body_payload_should_fail.............................PASS
in 0.000175381s
ucp::ucp_command_to_byte_should_work.............................PASS
in 0.000004265s
ucp::ucp_command_from_byte_should_work...........................PASS
in 0.000004306s
ucp::basic_encryption_impl_should_fail_with_different_keys.......PASS
in 0.000161823s
ucp::basic_encryption_impl_should_work...........................PASS
in 0.000146079s
ucp::algorithm_type_to_byte_should_work..........................PASS
in 0.000017134s
ucp::algorightm_type_from_byte_should_work.......................PASS
in 0.000003646s
frame::decode_frame_should_fail..................................PASS
in 0.000222516s
frame::encode_basic_encryption_should_work.......................PASS
in 0.000384216s
frame::encode_should_work........................................PASS
in 0.000272230s
frame::encode_should_fail........................................PASS
in 0.000014132s
frame::decode_a_single_frame_with_basic_encryption_should_work...FAIL
in 0.000557161s
frame::decode_a_single_frame_should_work.........................PASS
in 0.000551885s
frame::decode_frame_slice_with_invalid_frames_should_work........PASS
in 0.001136640s
frame::decode_frame_slice_should_work............................PASS
in 0.001206330s

.... ignore the rest

//
// Maybe even `fmt::println` starts from here
//

....

//
// Failures at the bottom
//
Failures:
frame::decode_a_single_frame_with_basic_encryption_should_work:
frame/+test/decode_single_frame_test.ha:65:31: assertion failed

//
// This line doesn't matter (at least not very important in debugging process)
//
15 passed; 1 failed; 16 completed in 0.004869804s
```

So, that's more clear and easy to figure out what's wrong, as usually,
the last `fmt::println` (debug print) is related to the error
directly, and `assertion failed` line points to which file which line.
You can spot the debug print and failure line in an easy way, then the
`debug idea` shows up in your mind immediately, that would reduce a
lot of debug time I think.

Otherwise, even if you print the full backtrace, that is still a lot
to read (another kind of mess up I guess), you still need to scroll up
to see the important failure info (which file which line), just better
than what you have so far:)

Of course, that's my personal feedback, not sure the right way to go:)

On Mon, Dec 30, 2024 at 8:02 PM Drew DeVault <sir@cmpwn.com> wrote:
>
> On Mon Dec 30, 2024 at 12:04 AM CET, Ye Wison wrote:
> > That’s what I did so far, but the problem of “fmt::println” is that it
> > messes up the whole test output results, as I have to print a lot to
> > figured out what’s wrong, I end up with scroll up a few seconds in
> > terminal to see the “hare test” result (which line fails), that’s quit
> > inconvenience and it happens a lot during the dev process….:)
> >
> > I’m hoping “hare test” somehow print the backtrace, that solves the
> > problem perfectly:-)
>
> Gotcha. As it so happens, I have a patch up on the mailing list which
> prints the backtrace for failed tests :)
>
> It would also make sense IMO to truncate long test logs.
Reply to thread Export thread (mbox)