Recently we started to convert all the tests of views into the PSR-0 name-schema.

Based on that you can observe that the amount of executed tests shrink.
As example compare:
http://drupal.org/node/1637624#comment-6127418
with
http://drupal.org/node/1563612#comment-6127356

The problem is that they run without any kind of problems on my local system, both via simpletest UI or run-tests.sh

Do you have any clue what is going on?

CommentFileSizeAuthor
#2 1642478-contrib-psr0.patch1.45 KBdawehner

Comments

dawehner’s picture

I'm totally not an expert in pifr, though i found the following code:

pifr_client_review_pifr_simpletest::test_list();

That code does

file_scan_directory($this->checkout_directory . '/' . $this->module_path($module), '\.test$');

so i guess this doesn't catch files like lib/Drupal/views/Tests/AccessTest.php

What about changing the $mask to *Test.php as well.

dawehner’s picture

Status: Active » Needs review
StatusFileSize
new1.45 KB

Here is a basic version of the patch, though i'm not sure whether this works as i don't have a local pifr setup

rfay’s picture

Yes, the command-line run_tests.sh is executed with a list of files it should look in.

So can you just say why tests are not in .test files any more? Before we make the change you request, we should understand that...

dawehner’s picture

As far as i understand it drupal8 will not have a registry anymore but just use PSR-0 compatible naming for its classes,
see #1513210: Meta: Start converting module provided classes to PSR-0 for the meta issue. So some people at the codesprint in barcelona moved all the many .test files to the new naming-schema.

I think that the tests for core still run, because all files are taken into account, though for contrib module only files specific for the module are used.

damien tournoud’s picture

See http://drupal.org/node/1543796

We need to look for tests in the Drupal\[module]\Tests namespace.

damien tournoud’s picture

Status: Needs review » Needs work

Here is the current code used by simpletest_test_get_all:

      foreach ($system_list as $name => $filename) {
        // Build directory in which the test files would reside.
        $tests_dir = DRUPAL_ROOT . '/' . dirname($filename) . '/lib/Drupal/' . $name . '/Tests';
        // Scan it for test files if it exists.
        if (is_dir($tests_dir)) {
          $files = file_scan_directory($tests_dir, '/.*\.php/');
          if (!empty($files)) {
            $basedir = DRUPAL_ROOT . '/' . dirname($filename) . '/lib/';
            foreach ($files as $file) {
              // Convert the file name into the namespaced class name.
              $replacements = array(
                '/' => '\\', 
                $basedir => '', 
                '.php' => '',
              );
              $classes[] = strtr($file->uri, $replacements);
            }
          }
        }
      }

We need something similarly ugly.

eric_a’s picture

Priority: Normal » Major

The silent way this happens makes it look at least major to me.
At first I was looking for some kind of naming mistake, inspired by #1632364: Write tests to ensure that all classes in Drupal can actually be found by the autoloader. But as it turns out there's no need to make one, ahem.

I was lucky that my conversion patch gave me zero passes which caught my attention, even when the bot came back green.
http://qa.drupal.org/pifr/test/289188

jthorson’s picture

Duplicate of http://drupal.org/node/1674290 ... just need to determine which patch makes more sense.

sun’s picture

Status: Needs work » Closed (duplicate)

Sorry, wasn't aware of this issue.

I've checked the patch and comments on this issue, and I'm 100% confident that the patch in #1674290: PSR-0 tests in contrib modules are not found is superior.

Ideally, of course, this part of PIFR wouldn't exist in the first place, and run-tests.sh would just simply do its thing. However, even though I'm actively working to make that vision happen, that's still a very long way to go.

jthorson’s picture

Fixed in #1674290: PSR-0 tests in contrib modules are not found and committed to 6.x-2.x. The next PIFR release should follow fairly quickly.