Make WordPress Core

Opened 4 years ago

Last modified 3 years ago

#48977 new enhancement

Add a new test case for E2E test

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


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.


  • 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 4 years ago.
E2E test code for the ticket
48977.2.patch (1.1 KB) - added by hideokamoto 4 years ago.
I forget to add any space with my code. It's new one.

Download all attachments as: .zip

Change History (3)

4 years ago

E2E test code for the ticket

4 years ago

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

#1 @isabel_brison
3 years 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:
There's also this draft: 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.