Thank you for taking the time to explain your perspective, this is exactly the kind of thoughtful feedback that helps me understand different testing philosophies.
Your distinction between assertions (preconditions/invariants) vs tests (things being verified) is really interesting. I can absolutely see how using different syntax helps communicate intent: "this MUST be true for the test to even make sense" vs "this is what we're actually testing". That semantic clarity is valuable, it reminds me of contract programming in languages like D where preconditions and postconditions have distinct roles.
You're absolutely right about the special assertion handling, that's definitely special behavior and I should have been clearer. What I meant was that the expressions themselves evaluate using Python's normal rules without hidden transformations. For example, Playwright's `expect(loc).to_have_text("text")` silently normalizes whitespace, so "hello world" might match "hello world". With plain asserts, `assert element.text == "hello world"` means exactly that: no normalization, no special matching rules. The expression evaluates the same way it would in a REPL.
But yes, extracting the failure details does require machinery that I'm not thrilled about either. It's the one compromise I made to support the plain assert syntax that many Python developers expect. But actually, you can use the `asserts` helper which does exactly what you described without any special handling:
from vedro import scenario, asserts as _
@scenario
def calculate_discount():
product = ...
discounted = apply_discount(product, 0.2)
_.assert_equal(discounted.price, 80.0)
I appreciate the consideration. I'll be watching Vedro with interest.
I do like the nicer vedro.asserts mechanism. If that works with unittest and pytest it would be really nice. You might get a few converts that way, too.
Your distinction between assertions (preconditions/invariants) vs tests (things being verified) is really interesting. I can absolutely see how using different syntax helps communicate intent: "this MUST be true for the test to even make sense" vs "this is what we're actually testing". That semantic clarity is valuable, it reminds me of contract programming in languages like D where preconditions and postconditions have distinct roles.
You're absolutely right about the special assertion handling, that's definitely special behavior and I should have been clearer. What I meant was that the expressions themselves evaluate using Python's normal rules without hidden transformations. For example, Playwright's `expect(loc).to_have_text("text")` silently normalizes whitespace, so "hello world" might match "hello world". With plain asserts, `assert element.text == "hello world"` means exactly that: no normalization, no special matching rules. The expression evaluates the same way it would in a REPL.
But yes, extracting the failure details does require machinery that I'm not thrilled about either. It's the one compromise I made to support the plain assert syntax that many Python developers expect. But actually, you can use the `asserts` helper which does exactly what you described without any special handling: