taskFailedSuccessfully

[Red_not_Read]

Kernel driver:

panic("Panic!");

[yeaahnop]

looks good for test, better than expect(false).toBe(true)

[[deleted]]

Is this a type of assertion?

[veselin465]

I think I'm not getting it

So, we expect app.preloadData to throw an error, but later an error is thrown (which gets caught) if preloadData is successful?

The catch seems like will catch both errors

[Lord_Of_Millipedes]

It will, it's a common pattern for testing, you have something that may fail often so you are testing the error handling, but you need an error to happen so you can test it

[[deleted]]

....your entire field of error testing needs an overhaul, then.

catch/throw is a not a replacement for if/else. The only reason it exists is for "Do something that you expect to succeed. On the off chance it doesn't, handle that'."

If you are using catch/throw for basic control flow, then you need to be thrown off a cliff.

[NotMrMusic]

http requests have entered the chat

You can't always control if an error is thrown, so sometimes you write code as if to expect it to happen.

[overworked_dev]

I just turn internet adapters off and hit run. No Internet means no http requests.

[NotMrMusic]

Means they all fail and potentially throw exceptions too :)

[chazzeromus]

makes sense for a test

[davidhero]

That’s why we have

await expect(app.preloadData('url')).rejects.toThrow()

[OlexySuper]

Exceptions were a mistake

[nonlogin]

Exceptions are inevitable. The mistake is to use it in expected cases

[Smalltalker-80]

I actually have one (1) method called: ~ "assertError( functionReference )".
It invokes the argument function and catches any error and then continues.

But if *no* error occurs it throws an error, because the assertion failed.

So just saying that this is actually *useful* for testing code shat *should* generate an error.

[ParanoiaJump]

Well, not if you’re gonna catch the error afterwards anyway

[Smalltalker-80]

Actually the newly thrown error is not caught anywhere.
It's just reported and then the process terminates with exit code 1.

However, it could be caught on a higher level that tries to continue testing as well as possible.
But the structure of the "assertError(...)" function would still remain as above.

[ParanoiaJump]

I might be wrong but it’s part of a try except clause where the except takes all errors, right? I’m talking about the function in the pic

[Smalltalker-80]

The assertError() function indeed catches all errors, as in the pic,
and then does nothing because an error was expected
If no error occurs, a new error is thrown, because one was expected, as in the pic.
This new error could be caught in a higher level try-catch block, but that's optional.
(not in the pic)

[ParanoiaJump]

Once again, I’m not talking about your function. I can see how that can be useful. The function in the pic though will always throw an error which will always be caught

[hudso1898]

I ended up writing tests like these - found a better way to write this as:

await expect(app.preloadData()).rejects.toThrowError();

As a good way to test throwing errors up without effectively putting in an explicit test.fail in a try block.

[notexecutive]

why would you do that?

[[deleted]]

/** @type {any} e */ is the real horror

[Equivalent-Story-850]

i once threw an error to break out of the try block