Write Feature File/s for Default Node view: project_issue_user_projects - Project issue ( your_projects.feature )

Hmm, it might be. Please indicate the URL you're using, and the search term your entering, and the expected results, and I'll have the ApacheSolr Team take a look at this issue.

FYI: The user login issue is being followed here #1720134: Script the re-creation of all needed test user accounts and passwords for git6site

Check and see if that expected content has been indexed by core search. (I've been told that it doesn't appear to be a solr thing)

@sdboyer: How often is cron being run on git6site (if ever)?

Regular site search won't index content until cron is run. The url pradeep pasted above indicates the test is checking to see that a newly created issue is found in the issue search, which seems like a meaningful test (at least I've had plenty of sites where cron quits running properly and content isn't indexed).

Once solution, assuming this is indeed the problem, could include running cron as a step in the test. The git vetted user won't be able to do this, though, so it's another situation where we either have sequentially dependent feature files or the test should be run by the 'admin test' user. afaik, the issue search functionality should be validly testable by either user.

Ideally, one might also like to validate that site search indexing is being run on the expected schedule and behaving as expected. Waiting for 1 hour or whatever the schedule is on a test seems fairly silly, though.

Thoughts?

the issue here is probably that, due to running out of space on the db server, we removed the search index for issues (which is still in the db, not solr). that saved 11GB. dww brought this problem up, and i imagine it's what we're seeing now.

i'm gonna leave this as postponed for now, as reincluding those tables in the db dump could easily result in overfilling our db servers again.

oh, and it looks like cron wasn't running at all on git6, not since the migration. i've turned it back on, in 15 minute increments.

Looks like one spot got missed or depends on something not yet committed in features/project/your_projects.feature

    And I press "Search" in the "content" region                                                 # FeatureContext::iPressInTheRegion()
      Notice: Undefined property: FeatureContext::$content in features/bootstrap/FeatureContext.php line 1781

+++ b/features/project/your_projects.feature
@@ -0,0 +1,117 @@
+Feature: Your Project Tab
+  In order to check the Projects created
+  As an authenticated user
+  I should be able to view the Projects created by the user and the issues associated

Add the actual business value and the right type of user:

  In order to easily manage the projects I've created
  As a project maintainer
  I should be able to find a list of projects and their associated issues in a central location.

+++ b/features/project/your_projects.feature
@@ -0,0 +1,117 @@
+    Given that I am on the homepage

This should be replaced with

    Given I am logged in as "git vetted user"
    And I follow "Your Dashboard"
    And I follow "Your Projects"

For every following scenario, all of the following should be deleted:

+    When I follow "Log in / Register"
+    And I am logged in as "git vetted user"
+    And I follow "Your Dashboard"
+    And I follow "Your Projects"

and the subsequent step should begin with When (unless it's an oddball one where you're just verifying all the data is present)

I think the more granular steps are appropriate here.

On a content level (correct me if I'm wrong), I'm seeing that these scenarios assume that data exists, but that data won't upon a fresh copy of the database is put in place (which will happen every time code is integrated) so this will fail in a continuous integration environment.

I've opened a meta issue on the topic #1742962: [meta] Create data for tests

Setting to needs work / postponed may be appropriate, too.

Since it appears that we'll be handling data set up in the background steps, would you revisit this and see if you can finish it now?

If you want to delete a bunch of those with the admin test account to see if it helps, that's the best I can suggest until we're getting more regular database refreshes. We don't really have the access we'd need to efficiently delete them after tests run, I don't think.

If you can have these clean up after themselves, that would be ideal; if access is a problem, then don't bother.

In the meantime, we're getting three failures:

 Scenario: Check the links in Project Table                                             # features/project/your_projects.feature:40
    And I am on "/project/user"                                                          # FeatureContext::visit()
    Then I should see the following <links> in column "Issue links" in "Projects" table  # FeatureContext::iShouldSeeTheFollowingLinksInColumnInTable()
      | links  |
      | View   |
      | Search |
      | Create |
    And I should see the following <links> in column "Project links" in "Projects" table # FeatureContext::iShouldSeeTheFollowingLinksInColumnInTable()
      | links       |
      | Edit        |
      | Add release |
      The link: "Add release" cannot be found in column: "Project links"

  Scenario: Check Add release link from Project Links column for Projects                # features/project/your_projects.feature:72
    And I am on "/project/user"                                                          # FeatureContext::visit()
    When I click "Add release" from "Projects" table                                     # FeatureContext::iClickFromTable()
      The link couldn't be visited.
    Then I should see "Create Project Release" page                                      # FeatureContext::iShouldSeePage()



  Scenario: Check Issue search                                                                   # features/project/your_projects.feature:108
    And I am on "/project/user"                                                                  # FeatureContext::visit()
    When I fill in "Search for" with Project Name                                                # FeatureContext::iFillInWithProjectName()
    And I select Project Name from "Project"                                                     # FeatureContext::iSelectProjectNameFrom()
    And I press "Search" in the "content" region                                                 # FeatureContext::iPressInTheRegion()
    Then I should see at least "1" record in "Project Issues" table                              # FeatureContext::iShouldSeeAtLeastRecordsInTable()
      The table: "Project Issues" cannot be found

I spent some time on the broken scenario today, and it seems to me that there's a fundamental problem with it:

  Scenario: Check Issue search
    And I am on "/project/user"
    When I fill in "Search for" with Project Name
    And I select Project Name from "Project"
    And I press "Search" in the "content" region
    Then I should see at least "1" record in "Project Issues" table

Instead of filling in "Search for" with the project name, I think you should be searching on the title of an issue (or text within an issue).

1. I tagged the scenarios that were dependent on test data with @dependent
2. In http://drupalcode.org/project/doobie.git/commit/a3e619b I added a call to cron to allow the searches succeed. tagged this scenario slow because it is
3. I split the sandbox and full project tests into separate files for readability and to simplify troubleshooting in the event of failures due to new functionality
   
   http://drupalcode.org/project/doobie.git/commit/33c3922
   
   http://drupal.org/node/1712286