Automated Tests 8.x topic needs an update

Please review, I have fixed the documentation.

Fixed, Please review.

In last patch, line's length is greater than 80 characters which is fixed in this patch, Thanks

1. +++ b/core/core.api.php
   @@ -1107,28 +1108,18 @@
   - * - For functional tests that do not test web output, define a class that
   - *   extends \Drupal\KernelTests\KernelTestBase. This class is much faster
   ...
   + * @section write_functional Writing kernel tests (PHPUnit)
   

   This is very close the section below which is
   * @section write_functional_phpunit Write functional PHP tests (phpunit) and that one talks about BrowserTestBase tests. Both BrowserTestBase and KernelTestBase tests are functional tests. I think we need to explain that and why you'd use KernelTestBase. From the documentation that is being removed it says that KernelTestBase tests are for functional tests that do not test web output which seems like a good start for explaining the differences.

2. +++ b/core/core.api.php
   @@ -1107,28 +1108,18 @@
   + *   This class is much faster than WebTestBase, because instead of making a
   

   WebTestBase => BrowserTestBase

@alexpott Can you pls tell me what should be the correct text so that i can make changes and write a correct patch for the issue ?

Fixing point 2 mentioned in #8.

Here's @jhodgdon's latest patch from the other issue to get us re-started over here.

IMHO, nothing about our testing world, especially not documenting the weirdness, is "novice". ;)

+++ b/core/tests/README.md
@@ -1,114 +1,76 @@
+Create a directory called simpletest in sites/default and make sure that it it

I create my directory in sites/simpletest. I'm not sure that sites/default/simpletest would be used. Also two "it".

+++ b/core/core.api.php
@@ -1083,123 +1083,70 @@
+ *   start with 'test' and have no arguments; for example, testYourTestCase().
+ *   For unit tests, you can also use @covers and @dataProvider annotation
+ *   to indicate a test method.

Hmm this is still not entirely accurate. I would just leave out the 'and have no arguments' and the sentence about @covers and @dataProvider because then you would need to explain the whole when/how/why/why not of that too or leave people with more questions then they got here with. We should elaborate on that in https://api.drupal.org/api/drupal/core%21core.api.php/group/testing/8.7.x or maybe https://www.drupal.org/docs/8/phpunit/phpunit-browser-test-tutorial ? I would opt for the first one because that would allow us to explain that you can and should use @dataProvider for unit and kernel tests, and can but SHOULDN'T use it for functional/javascript tests. And the tutorial would only allow us to explain not using it, which doesn't sound very helpful.

Other then that, this looks like a massive improvement.

"usually" might be putting it a bit strong, but not a problem I feel.

Looks great, lets see if others agree.

I think the text would be better without mentioning data providers - why are we mentioning them here?

My comment in #18 was mostly about just giving some background on why stating that methods have no arguments was misleading, less about putting something about that into the text, sorry if that got lost in translation somewhere :-)

I think dataProviders are a great feature of PHPUnit tests so that is why I had no problems with the text mentioning them, but I get that this might be a little bit more in-depth then this doc should aim for. So here is my stab at taking that bit out.

I thought that the name of the test methods wasn't important after all?

It is, it has to start with 'test' or phpunit won't think its a test method.

This is a really great clean up. I have one concern...

+++ b/core/tests/README.md
@@ -1,114 +1,76 @@
-## Running tests with a different user
-
-If the default user is e.g. `www-data`, the above functional tests will have to
-be invoked with sudo instead:
-
-```
-export SIMPLETEST_DB='mysql://root@localhost/dev_d8';
-export SIMPLETEST_BASE_URL='http://d8.dev';
-sudo -u www-data -E ./vendor/bin/phpunit -c core --testsuite functional;
-sudo -u www-data -E ./vendor/bin/phpunit -c core --testsuite functional-javascript;
-```

@@ -138,3 +100,15 @@ If your core directory is located in a subfolder (e.g. `docroot`), then you can
+## Troubleshooting test running
+
+If you run into file permission problems, you may need to invoke the phpunit
+executable with a user in the same group as the web server user, or with access
+to files owned by the web server user. Also, to maintain web server user access
+to files created by tests, make sure that you have
+`$settings['file_chmod_directory'] = 02775;`
+in your settings.php or local.settings.php file.
+
+You may need to use absolute paths in your phpunit.xml file, and/or in your
+phpunit command arguments.

For me this is too common a situation to not detail in this file. Let's move some of this example into the troubleshooting section. It's far more common that the necessity to do the settings change.

@jhodgdom agreed, the export stuff isn't needed. Feedback has been addressed I feel, back to RTBC and lets see if @alexpott agrees.

1. +++ b/core/tests/README.md
   @@ -138,3 +100,20 @@ If your core directory is located in a subfolder (e.g. `docroot`), then you can
   +sudo -u www-data ./vendor/bin/phpunit -c /path/to/your/phpunit.xml --group Groupname
   +
   +
   +Also, to maintain web server user access to files created by tests, make sure
   

   Is the double line intentional?

2. +++ b/core/tests/README.md
   @@ -138,3 +100,20 @@ If your core directory is located in a subfolder (e.g. `docroot`), then you can
   +Also, to maintain web server user access to files created by tests, make sure
   +that you have
   +`$settings['file_chmod_directory'] = 02775;`
   +in your settings.php or local.settings.php file.
   

   I think this language is a bit strong. This is very much a maybe in certain very rare situations type of thing. I do think it is worth noting here but it's more a try this if you have file permission issues.

Let's do the 80 char thing in a follow-up.

I like the new text.

Committed and pushed 446586b60a to 8.8.x and 4a701c007a to 8.7.x. Thanks!

This patch removed all mention of selenium:

-* Install selenium-server-standalone and chromedriver

Could someone explain why -- did it cease to be needed, and if so, for which version of Drupal core?

If older versions of core do need it, then https://www.drupal.org/docs/8/phpunit/running-phpunit-javascript-tests should mention that.