Thank you for your comments. It gives me more points of view in using assertions commands. I would like to discuss with some of your opinions. Mixture of verification is still there if you use assertions in both PO and Test level, even these assertions are wrapped in any utils method or class. As I mention in my post(s), we should define a responsibility for each layer of our code. PO should have only its own responsibility, that is, to describe the business actions or flows. You mentioned PO like API schema, I think it’s not appropriate. I think PO method like API, and its parameter should be like the API schema and returned values as the API responses. "Verify component01" I’m not sure whether it is for a specific test case? If not, I think it should not appear in the code. "verify for test01" means some lines of code will check according to the purposes of the test. And the purpose includes verifying something on a page, and others. From my point of view, Test will be presented like a user story (template “As a [persona], I [want to], [so that].”, or GIVEN WHEN THEN). Of course, it could include some additional information as well. The assertions commands (or wrapped utils methods) would be the implementation of "so that" or "THEN" clause. It should be appeared on test level for easy understand and review. If you put verification to lower layer, reviewers have to navigate to many places to understand fully your checkpoints of test case.