WordPress.org

Make WordPress Core

Opened 20 months ago

Last modified 5 months ago

#48977 new enhancement

Add a new test case for E2E test

Reported by: hideokamoto Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Build/Test Tools Keywords:
Focuses: javascript Cc:

Description

Now the E2E test has only one case to test WordPress.
So we can add a new test case

Test case
WordPress has two default content.

  • Post "Hello world", post_id=1
  • Page: "Sample Page", post_id=2

So we can test to these page are these page exists.

Expect

  • localhost?p=1 -> should return HTTP200
  • localhost?p=2 -> should return HTTP200
  • localhost?p=404 -> should return HTTP404

Attachments (2)

48977.patch (1.1 KB) - added by hideokamoto 20 months ago.
E2E test code for the ticket
48977.2.patch (1.1 KB) - added by hideokamoto 20 months ago.
I forget to add any space with my code. It's new one.

Download all attachments as: .zip

Change History (3)

@hideokamoto
20 months ago

E2E test code for the ticket

@hideokamoto
20 months ago

I forget to add any space with my code. It's new one.

#1 @isabel_brison
5 months ago

Hi @hideokamoto , thanks for your contribution!

The aim of having e2e tests in Core is to comprehensively check user flows, to help relieve the burden of manually testing every single flow after a change. They are particularly useful in catching regressions of the kind where a change in one place causes an unexpected effect in a different part of the code.

To that effect, the most useful approach is to test all the possible actions on a page, as opposed to checking that the page itself renders. A great example of that approach is the Gutenberg e2e tests for the block editor: https://github.com/WordPress/gutenberg/tree/trunk/packages/e2e-tests/specs/editor
There's also this draft: https://github.com/WordPress/wordpress-develop/pull/200 for adding tests for the Posts page, which proposes a similar approach for Core.

Looking at your patch, you are checking that the default post/pages are rendering on the front end. This can be problematic because e2e tests can sometimes delete all content from the testing environment before running a test, and that means the default content won't always be found in the environment. We also can't assume the tests are going to be run in a certain order.

I'm on the fence as to whether we should be testing front end pages at all, as imo these tests should focus on the admin itself, but perhaps if e.g we're testing a flow where a post is published, it might make sense to check that the post exists after publishing.

With that in mind, would you be open to writing some new tests that follow the above guidelines?

Note: See TracTickets for help on using tickets.