Simple test menu items shouldn't be under "Configuration"

Novice attempt at rolling the patch.

It is a development tool, so I moving it away from me doesn't make sense to me. Just my 2 cents.

Well, it has a settings page, agreed, not a big and interesting one of course hehe.
Reports has pages like statistics too, they're not interesting for development imo. Anyway, it feels natural for me to be under development, but I won't make a big deal if it moves :)

TBH, I wouldn't even be opposed to "Development" actually being a top level menu item.

That would make a lot of sense to me too.

I think this might need more discussion. You are going to befuddle a lot of developers with this change.

Yeah, I'm not sure about this, personally. Reports says to me "read only" and there's quite a bit of interactivity with the SimpleTest-related things. I also think it's odd to take such a developer-focused menu and move it away from the "Developer" sub-section in Configuration.

Let's get some of the UX team to chime in.

The question is what kind of task it is, to me its in the same mental space as configuring/developing your site. While semantically you could argue its a report, in use it doesn't really stand close to static report pages.

The space that people look for this kind of functionality is the Development category, just like devel, performance etc. I don't think it makes much sense in reports - even though semantically it could be correct. It's more about task flow, than it is about semantics - and the task flow leads you to this category, as its where you go to interact with configuring/running development tasks.

Honestly, I think the whole reports section is a little wierd :) But that's just my point of view.

Regarding #14, I think you're being overly concerned with semantics, both in your argument and in making it. As a developer, I know that I look for the stuff that I need to do all the time when developing under development. This incudes synching my configuration, running and debugging automated tests, clearing and configuring my caches, etc. Nothing among it is remotely a report. Moving one item out of there is silly and would annoy me, as a developer in the tiny tiny minority of Drupal users who actually enable the testing module and in fact use it constantly.

99.9% of site builders will never see this module, because the only people who use it are developers. For the same reason, we should not clutter the top level of the IA with "Development."

Finally, to me, SimpleTest results aren't a report. They're an interactive debugging tool. :)

I was just about to file a similar issue as I always find it confusing that "Testing" is under configuration.

Testing is not configuration in any sense. It's also not a report.

I wouldn't mind it creating another top level menu item since it doesn't fit comfortably in any of the existing menu parents. Also, developers are likely the only ones who will have this enabled, so that would make it more visible and require fewer clicks to get to.

Added issue summary template.

Couldn't apply the patch. Attached is the error log.

Recreated the patch. Drupal 8 has changed dramatically from the times when the original patch was created.

I apply the patch and test the (admin/config) and i don't see the testing
and go to (admin/repots) and see the testing and work fine.

Patch no longer applies, tagging for reroll.

reroll

Patch applies cleanly without error...

the is no issues creep this patch addresses only what is need to get the job done.

Manual Testing :-

1) Installed drupal with patch -- without anything appearing in the php_error.log ( so far so good )
2) >Extend -- added testing.
2) Am I wrong was expecting "testing" to no longer appear in the Development sub-section - It appears with the adjusted URL of "admin/reports/development/testing" + the links still work. But looks out of place with all the other URLs which start 'admin/config/development'
3) the newly adjusted local tab "admin/reports/development/testing/settings" works as expected...
4) From the issue summary I was expecting to see a shiny new testing entry on the 'admin/reports' page but could not.

In summary have I missed the point? As only the link names have changed and The "testing" subsection has not moved from one page into a table entry on another?

There are a whole bunch of development related modules available on drupal.org. None of them really fits into any category of the current admin IA.

Instead of moving Simpletest (again) from one inappropriate category to a new inappropriate category (formerly located in Build [now Structure]), we should introduce a new top-level admin menu category:

"Develop"
/admin/dev

That idea came up at least a dozen of times in past discussions already (but I wasn't able to find an issue for doing it).

→ admin/dev/testing

If it's a health check, then it's a validation test. If it's a validation test, then it should be considered a configuration test since we are not about to add modules that are not healthy to the config.

Rerolled the patch in #26 to apply to the head.
Also changed the paths for testing to appear under reports/testing and not reports/development/testing as there is no parent path and no obvious way to link to simple test with the old patch.

Working on reviewing the patch.

I applied patch provided in #33. It fails to apply on latest 8.0.x branch. It needs to be recreated. Working on it.

I also tried #33. Failing on my instance as well.

Recreated #33 patch. Needs to review.

For the testbot

rerolled

1. +++ b/core/modules/simpletest/src/Form/SimpletestSettingsForm.php
   @@ -42,7 +42,7 @@ public function buildForm(array $form, FormStateInterface $form_state) {
   -      '#description' => $this->t('By default SimpleTest will clear the results after they have been viewed on the results page, but in some cases it may be useful to leave the results in the database. The results can then be viewed at <em>admin/config/development/testing/results/[test_id]</em>. The test ID can be found in the database, simpletest table, or kept track of when viewing the results the first time. Additionally, some modules may provide more analysis or features that require this setting to be disabled.'),
   +	  '#description' => $this->t('By default SimpleTest will clear the results after they have been viewed on the results page, but in some cases it may be useful to leave the results in the database. The results can then be viewed at <em>admin/reports/testing/results/[test_id]</em>. The test ID can be found in the database, simpletest table, or kept track of when viewing the results the first time. Additionally, some modules may provide more analysis or features that require this setting to be disabled.'),
   

   tab prefix in line

2. +++ b/core/modules/simpletest/src/Tests/SimpleTestTest.php
   @@ -129,7 +129,8 @@ function testWebTestRunner() {
   -        $this->drupalGet('admin/config/development/testing');
   +        $this->drupalGet('admin/reports/testing');
   +        $this->drupalGet('admin/reports/testing');
   

   why that called twice

thnx, @andypost, fixed

Let's get commiter's feedback

Not sure I agree with this. Reports are passive, simpletest is active. Also it's purely a developer tool, not a site-admin tool which reports are mainly for.

Also not seeing a screenshot here.

Seems to me that *if* this should be moved somewhere else, then it should be into a new "Development" top level category (of which we already have 8) but that's a different (perfectly ok to have) discussion.

Moving this from /admin/config/development/ to admin/reports/ means moving it out of the Development sub section which doesn't look like an improvement, because there *is* consensus that Testing is about Development.

So even though Development is not quite comfortable to some *as a section under Configuration*, it looks like we shouldn't move Testing out of Development, especially since all the other items in Reports aren't about development either.

Thanks @yoroy. The fact it'd move out of the development item and the potential to maybe add a top level development item I hadn't thought of, but both are very good reasons not to do this.

Going to mark this 'by design'.