To begin, I'll start with the "Account Settings" section. I won't be working on any of the frontend in this, or next next few, posts. Instead, I'll focus on getting the backend functionality working with tests.

December 02nd, 2017

Goal

To begin, I'll start with the "Account Settings" section. I won't be working on any of the frontend in this, or next next few, posts. Instead, I'll focus on getting the backend functionality working with tests. This post will show a look into some of the TDD practices I use to build out features. It will include almost every detail of the process. However, in future posts, I'll try to reduce this down since segments of the process are formulatic and can just be generalized.

Tests and Development

Before setting up the page and form, I will think of all the tests that should be performed for this feature. I won't always figure out every test from the beginning but I will do the best I can. This really helps me work through the build process. Tests make it super easy to check your code as you work. Before I started writing tests, I would really depend on constantly refreshing the browser to flush out issues. These test also work as a sort of "check list". It gives me an idea of how much work is needed to build out a feature. I'll get started by making my first test.

Obvously the test will fail since we haven't setup a route. This is good though. I like letting the tests guide me through the build process. This works especially great in Laravel since the errors can be very explicit. In this case, the 404 just tells me the route doesn't exist. Let's add the route and rerun the test. I'll truncate the errors moving forward.

Ok, so we are hitting the controller method as a guest user and getting a 200 instead of the 401. How should we handle it? Laravel ships with a piece of middleware that can be applied to prevent guests from accessing routes that require authentication. There are many places to applied this middleware. In this case, I will add it in the endpoint controller's construct method. This will also apply to the authentication tests for the other verb tests as well.

If you notice, I'm using a helper called "factory". Model factories are a great way to create fake data for testing. In this case, we are telling the test to create a new user and store them in the database. Laravel provices a default User factory located in database/factories/UserFactory.php. Then we hit the GET endpoint "acting as" a newly created user who has been authentiated. Finally, we check that the view did receive the required user information. Let's run the test.

We get a 200 since there is no validation for this request. To manage validation we'll use Laravel's custom "Form Validation" class. Let's create one for this request and inject it on the update method.

This will allow me to update $user = factory(User::class)->create(); to $user = $this->createUser();. In addition, I can also update $this->actingAs(factory(User::class)->create()) to $this->actingAsNewUser().

Next, I'll look at the validation tests. I know I'll be writing at least another 40 or so validation tests. So let's reduce the code we will need to write.

After updating all the other test methods with the new helpers and running the tests I get all green. There is more that could be done but I'm ok with this so far. For most of these features, I won't be building any of the front end until most of the functionality is tested and built. So for the next post, I'm moving right on to the next feature without writing any HTML.