Finish FunctionalJavascriptTests

Finishing them in here now, since i need to test these on the Drupal Server, so there might be a lot of commits in here!

I'm not sure why but it seems like the Drupal-Serverside-Test is not appearing here. Postponing this until this issue has been resolved. We should also definitely take a look at this issue here 📌 Put list page back to a view Closed: works as designed before continuing to put any effort into this one!

seems like the Drupal-Serverside-Test is not appearing here

What exactly do you mean?

Perhaps you mean this needed to be rebased on the latest project commit?

The problem is that, on other issues whenever you push a commit, there is like a specific testing button below the issue branch and also appears as a separate message like a comment. E.g. https://www.drupal.org/project/photoswipe/issues/3021978 ✨ [5.x] Add photoswipe options UI (and optionally setting presets) Fixed , there it says "Pass" below the issue branch. And that is the system I was supposed to use to test the FunctionalJavascript tests that don't work on my local page. However, this does not appear here. How do I get this working?

Found it! Tests were not enabled in the project here: https://www.drupal.org/node/3372791/qa →

The last submitted patch, 11: 3381719.patch, failed testing. View results →

Anybody → closed merge request !6

Anybody → reopened merge request !6

Ok tests are still failing. :(

Yes, now that this works I'm getting back to this. However, there is an issue with the PHPUnit tests right now:
We have implemented a WYSIWYG-editor for the body of a content entity, and for that we need to set its type to "text_long". Unfortunately PHPUnit does not know this particular type and wants us to use "string_long" which is just plain string text. What sould we do? Our test might always fail at this point...

Unfortunately PHPUnit does not know this particular type

PHPUnit only runs the tests, based on the setup we give it. If there is something unknown, which isn't unknown inside your "normal" setup, it is the test setup's fault, not PHPUnit's.

Note, that when we set up Functional and FunctionalJs Tests, the initiated Drupal instance is always initiated with very few modules installed (Even most core modules are not installed by default). Meaning, if you get an error like this, to 99% the problem lies in a missing module installation.

In this particular case, we were missing the Drupal core "text" module.

Also note, that we currently have a lot of Test classes in different submodules, which all extend "BrowserTestBase". With so many different Test classes, which basically need the same setup, it is always good to define a "parent" Test class which handles the modules to install and the setup. This way, we can have a lot less code inside every other class extending our parent class.

Another note, if commit something, and see something along the lines of:

PHP 8.2 & MySQL 8, D10.0.7 Waiting for branch to pass

Click on "Waiting for branch to pass" and skip the passing. This is always needed for test changes.

Pushed my changes for now, but I have run into the problem that on the version that this branch was created on, the ListJS is not working in its entirety (haha), so obviously I can't test it. I think it is working again in a newer version, we should update this issue to that version.

@LRWebks that just means we needed to rebase the MR. I just did that. So the fork is now on the latest 1.x-dev status plus your changes. Please pull and retry!

Yes, I still need to fix the ListJS behavoir, when I implement the custom sidebar / navigation.

See https://www.drupal.org/project/project_wiki/issues/3384518#comment-15213229 📌 Search and implement a proper navigation solution Active

This will probably have an impact on the tests? So this is probably blocked.

Thanks, turns out I just forgot to install the third-party library required by ListJS but not automatically installed. (whoops)

This will probably have an impact on the tests? So maybe this issue is blocked.

No it's not blocked. This should be finished now, and you can align the tests later then, in your MR for the navigation revamp.

@LRWebks: The testing error:

The "text_long" plugin does not exist. Valid plugin IDs for Drupal\Core\Field\FieldTypePluginManager are: uuid, uri, timestamp, string_long, string, password, map, language, integer, float, entity_reference, email, decimal, created, changed, boolean

is due to the fact that the "text" module isn't enabled in the tests!

Problems with the test again, whenever I try to enter anything into the search field via code, nothing is actually entered and all test entries mysteriously disappear... Don't know what that's about. @Grevil, would you mind taking at look at this?

@Grevil: We took this as far as we could, but I have no clue what's wrong with the JS input... perhaps you have an idea, but as we'll presumably replace ListJS, please don't invest too much time.

But have a look, perhaps you have a clever guess, why the list is empty as soon as ANY search term is entered, but the search term is also not visible... crazy!

Is it working locally, but not on remote? Since we do not provide list.js via cdn, the js lib is simply not present on the remote.

So we need to create a test module, which modifies the library source to use a cdn source instead.

@Grevil no sadly it's also *not* working locally, where the lib is present.

For adding CDN see 🐛 Fix coding standard issues Active

but as written above, we shouldn't invest too much time until we're sure we'll keep list.js

For adding CDN see #3387512: Fix coding standard issues and failing test

What the hell? This seems hella out of scope. Please see my updated comment on how to use CDN in tests.

Well, reproducing the test in a live setup also doesn't work either:

Meaning, it's not the test's fault.

Same behavior on 1.x-dev. Meaning, the search simply doesn't work.

Please pull the setup changes done in this MR first and use this issue to fix up the search functionality. Afterward, the tests can be implemented.

Managed to fix the ListJS implementation! (Cause were some screwed up class names in the twig template that occured during the twig restructuring), searching and sorting works again as intended. @thomas.frobieter: In your twig code you proposed a new naming system: project-wiki-list-entry__[name], I kept it that way and refactored the new class names accordingly (you forgot developerContent btw.)
Taking a look at the test again now!

Guess this sadly was a worthless change, because as mentioned in #25, I still need to build a custom sidebar / navigation solution for this project. Afterwards the filtering is done inside the sidebar and only the currently active article will show up on the right side.

So currently its not worth investing more time in the filter solution!

Further Details: https://www.drupal.org/project/project_wiki/issues/3384518#comment-15213229 📌 Search and implement a proper navigation solution Active

The search test is working! It's open for review again! However, there still is the sort test, but I'm really not sure how to implement it, since all method I find to be available to me are "element is there" or "is not there", but with the sorting all elements are there, only the position matters! Any suggestions?

Just read @thomas.frobieter's comment, guess this issue is bound to be "Closed (won't fix)"-ed?

We should simply postpone this topic, to much things change, this will just end up in doing stuff twice.

The future changes should not stop us from merging the fixed tests and closing this issue. We can (and should) add further tests later.
The last changes by @LRWebks LGTM.

Let's wait for the test to finish.

@LRWebks: Now it seems to be a different (PHP) issue. So please proceed with that one, as it will be needed to work despite the frontend changes.

Testing Drupal\Tests\project_wiki\Functional\ProjectWikiInstallTest
E                                                                   1 / 1 (100%)

Time: 00:03.417, Memory: 4.00 MB

There was 1 error:

1) Drupal\Tests\project_wiki\Functional\ProjectWikiInstallTest::testInstallUninstall
Exception: Warning: Undefined array key 0
Drupal\project_wiki\Controller\ProjectWikiController->build()() (Line: 45)

The future changes should not stop us from merging the fixed tests and closing this issue. We can (and should) add further tests later.

I agree with @Anybody here.

I just had a quick load at the code, concerning the PHP error, should be a quick fix @LRWebks, if you have any questions, feel free to ask them!

So, I suppose I'm also tackling all the remaining failing test issues in here? I'll be doing that now!

Okay...
I fixed the tests, but we seem to have run into a "server-only" instead of "local-only" test-error this time! The tests all work locally for me, would you mind to check if they work for you locally as well? If that is the case, we can probably ignore the failing tests here on the server, right?

Nope, both have to run. "Runs locally" is no excuse :D

$projectWikiContentValueObjectInstances = $this->pluginManager->createInstances();

doesn't seem to return an array in this case, being called in
/var/www/html/modules/contrib/project_wiki/tests/src/Functional/ProjectWikiInstallTest.php:60

as you can see from the stacktrace.

I don't have an idea yet, why that should work locally, but not here.

Yiiiha, tests are passing, congratulations! :)

@LRWebks: Please open a follow-up for the Markdown text filters tests.

Automatically closed - issue fixed for 2 weeks with no activity.