User commits (user_commitlog.feature)

Commit numbers - Check that commit numbers are lower than in d.o.
[Sundar]: Should we count the total number of commits in this page? Because, the total commits number is not displayed in this page.
[Melissa]: The per-project commit numbers are on the user profile page, not the Your commits tab so this check belongs with that page and not with this issue.

Links: Number - Link should go to commit
[Sundar]: Not sure where to look for this. Please provide more information.
[Melissa]: Date goes to the individual commit record

Links project name (full project) - Link should go to profile
[Sundar]: I think this should link to the project node and not the user profile. Please clarify.
[Melissa]: You're correct, project name should link to project

Links: file name - Link should go to file repo viewer
[Sundar]: I think this is the 8 character hash. Please clarify.
[Melissa]: Correct again

Links: diff - Link should go to diff from previous version
[Sundar]: No diff links found in commit screens. Discarding this item.
[Melissa]: Yep, discard.

Please review the Given/When/Then structures in the .feature file
http://drupal.org/node/1578324#important

The pre-made user used for these tests, site user, should never have any commits as they are set up explicitly *not* to have agreed to the terms of service. It seems like we need to set up a user who has actually made commits in order to validly see that commits are appearing.

I'm assigning this to look into more closely tomorrow.

Yes, i think postponing this is appropriate. Marking as such.

Unassigning. Still postponed afaik.

Since we're going to be creating data in background steps, this can probably be revisited now.

This is similar to #1706806: Edit profile (SSH keys) (edit_profile_sshkey.feature)

a) data set up should happen in the Given to avoid dependent scenarios
b) each scenario should have one (and only one) for given, when, and then. This can be achieved by rewriting the pushes to be part of the When steps (which they really are)

And I push a commit to the repository

And then combining the scenario with the one which follows, since it contains only the "then" section anyway.

tagging

Also throwing fatal errors:

  Background:                          # features/project/user_commitlog.feature:6
    Given I am logged in as "git user" # FeatureContext::iAmLoggedInAs()
    And I follow "Your Dashboard"      # FeatureContext::clickLink()
    And I follow "Your Commits"        # FeatureContext::clickLink()

  @gitrepo
  Scenario: Git User creates a project                             # features/project/user_commitlog.feature:12
    Given I am at "/node/add/project-project"                      # FeatureContext::iAmAt()
    And I create a "module"                                        # FeatureContext::iCreateA()
PHP Fatal error:  Call to a member function getAttribute() on a non-object in /home/melissa/doobie/features/bootstrap/FeatureContext.php on line 351

Great. No fatal errors, so this is ready to move forward.

I questioned briefly whether the feature should be an authenticated user or a contributor, but a user should and does still see his or her contributions even if they no longer consent to the terms of service so it seems right as-is.

An aside: I've opened a separate issue in the DrupalExtension for the built-in steps on "I am at/on" and "I visit"; if these a page exist but Drupal denies access, I'd sure appreciate having that information displayed instead of having the subsequent step fail. #1781464: Return exception if access is denied or page is not found

Unassigning

merged into master

This test is failing in the following scenario when run cold and succeeding every time thereafter until some unknown period of time has passed. Sadly, I don't have the error text. This might be a good candidate for the warm up step. I'll try to reproduce the error and we can go from there.

Scenario: Git User creates a project # features/git/user_commitlog.feature:13

This failed for sdboyer on the bddtest server, too, so I know something is up. I don't doubt that you can't reproduce because these errors are frustratingly erratic. This is tagged as flaky on the scenario, and I'll leave it that way.

I've tagged it for retest after next build and will be working with it as I work with the other erratic failures, but I think this is bigger than the single issue and possibly not something the test can be adjusted to account for.

We've done as much as we can with this until D7 Drupal.org is ready for feedback.