Password Management - Change Password - Part 2

This video is available to view for members only.

Click here to Join!

Already a member?

Login


The last part of getting our Change Password functionality working is to check that it does work as you expect - even if you sometimes expect people to do it wrong. With the best will in the world, everyone makes mistakes. Not everyone doing the wrong thing is malicious.

Or simply, the "unhappy paths".

Here's the Behat feature now, in full:

# /src/AppBundle/Features/password_change.feature

Feature: Handle password changing via the RESTful API

  In order to provide a more secure system
  As a client software developer
  I need to be able to let users change their current API password


  Background:
    Given there are Users with the following details:
      | id | username | email          | password | confirmation_token |
      | 1  | peter    | peter@test.com | testpass |                    |
      | 2  | john     | john@test.org  | johnpass | some-token-string  |
     And I set header "Content-Type" with value "application/json"


  Scenario: Cannot hit the change password endpoint if not logged in (missing token)
    When I send a "POST" request to "/password/1/change" with body:
      """
      {
        "current_password": "testpass",
        "plainPassword": {
          "first": "new password",
          "second": "new password"
        }
      }
      """
    Then the response code should be 401

  Scenario: Cannot change the password for a different user
    When I am successfully logged in with username: "peter", and password: "testpass"
     And I send a "POST" request to "/password/2/change" with body:
      """
      {
        "current_password": "testpass",
        "plainPassword": {
          "first": "new password",
          "second": "new password"
        }
      }
      """
    Then the response code should be 403

  Scenario: Can change password with valid credentials
    When I am successfully logged in with username: "peter", and password: "testpass"
     And I send a "POST" request to "/password/1/change" with body:
      """
      {
        "current_password": "testpass",
        "plainPassword": {
          "first": "new password",
          "second": "new password"
        }
      }
      """
    Then the response code should be 200
     And the response should contain "The password has been changed"

  Scenario: Cannot change password with bad current password
    When I am successfully logged in with username: "peter", and password: "testpass"
     And I send a "POST" request to "/password/1/change" with body:
      """
      {
        "current_password": "wrong",
        "plainPassword": {
          "first": "new password",
          "second": "new password"
        }
      }
      """
    Then the response code should be 400
     And the response should contain "This value should be the user's current password."

  Scenario: Cannot change password with mismatched new password
    When I am successfully logged in with username: "peter", and password: "testpass"
     And I send a "POST" request to "/password/1/change" with body:
      """
      {
        "current_password": "testpass",
        "plainPassword": {
          "first": "new password 11",
          "second": "new password 22"
        }
      }
      """
    Then the response code should be 400
     And the response should contain "The entered passwords don't match"

  Scenario: Cannot change password with missing new password field
    When I am successfully logged in with username: "peter", and password: "testpass"
     And I send a "POST" request to "/password/1/change" with body:
      """
      {
        "current_password": "testpass",
        "plainPassword": {
          "second": "missing first"
        }
      }
      """
    Then the response code should be 400
     And the response should contain "The entered passwords don't match"

Again, nothing new to define here. All of these scenario step definitions live in our RestApiContext file. If you aren't the kind of person who usually writes tests, this is an easy way to start, and immediately see some benefits.

We also don't have any new code to write here. I love writing tests like this. The system responding as expected without extra logic needed.

I thought we were supposed to be on the unhappy path :)


Code For This Course

Get the code for this course.

Share This Episode

If you have found this video helpful, please consider sharing. I really appreciate it.


Episodes in this series

# Title Duration
1 Course Overview & API Walkthrough 04:23
2 Setup - Bundles & Config 08:37
3 Setup - Behat 04:45
4 Login - Part 1 - Happy Path 06:58
5 Login - Part 2 - Being Careful of Edge Cases 02:28
6 Profile - Part 1 - Happy Path 05:33
7 Profile - Part 2 - Unhappy Paths 01:50
8 Profile - Part 3 - Updating (PUT) - Happy Path 09:12
9 Profile - Part 4- Adding PATCH - Happy Path 06:21
10 Password Management - Change Password - Part 1 07:30
11 Password Management - Change Password - Part 2 04:13
12 Password Management - Reset Password - Part 1 06:14
13 Password Management - Reset Password - Part 2 05:37
14 Password Management - Reset Password - Part 3 05:57
15 Password Management - Reset Password - Part 4 03:51
16 Registration - Part 1 - Happy Path 06:56
17 Registration - Part 2 - Happy Path 06:42
18 Registration - Part 3 - Unhappy Paths 02:08
19 FOSUserBundle User Entity Serialization Improvements 02:11
20 Customising Your Encoded JWT 03:56