[test] Migrate from assert to expect #20799
Conversation
oliviertassinari
changed the title
How does this PR reduce confidence and why does this not apply to actual production code e.g. |
@eps1lon This part was a digression, you know, it's my routinely fear with API like |
Details of bundle changes.Comparing: d6faf6f...e113a91 Details of page changes
|
oliviertassinari
force-pushed
the
assert-to-expect
branch
from
1a924d8 to
878d6a3
Compare
|
There is one aspect we need to be cautious with: the codemod drops the custom failing messages. If we want to keep them, an extra iteration is required. For context, Jest doesn't allow them. |
I don't like chaining either. Since we all agree on that we could just mimic how jest-expect works by applying the same approach as |
github-actions
bot
added
the
PR: out-of-date
oliviertassinari
force-pushed
the
assert-to-expect
branch
from
878d6a3 to
d6a0419
Compare
@marcosvega91 I think that it depends. In the case of this pull request, we have a fast path for 1. and 3., hence we should take it. However, as I mention in the description, the codemod really optimize for the efficiency, for effectiveness, we have to revisit it. In any case, I think that we have to be humble and internalize that there are infinite levels of complexity, no matter how far we push a solution to a problem, we will always be able to improve it. If you could take care of the few last imports of |
oliviertassinari
removed
the
PR: out-of-date
|
@oliviertassinari Yes I know but my mind goes directly to the most complex. |
github-actions
bot
added
the
PR: out-of-date
oliviertassinari
force-pushed
the
assert-to-expect
branch
from
d6a0419 to
fcf97df
Compare
oliviertassinari
added
PR: ready to ship
and removed
PR: out-of-date
Follow-up on #20792. I have focused on the migrating most of the API: efficiency (not effectiveness). There are still a couple of assert in the code base, related to usage of non frequent API:
IMHO, the simplest would be to update the assertion to
expect().to.equal(), we want to have high confidence in the assertion, I still think that higher confidence outweighs the advantage of better error messages, but no strong preference. I know we went for the other way around, I don't intend to change the current tradeoff.There are also a couple of files that jscodeshift failed to handle, some unsupported syntax error. I haven't looked at it.