paint-brush
What should we be testing in a [laravel] CRUD application?by@djug
114,472 reads
114,472 reads

What should we be testing in a [laravel] CRUD application?

by Youghourta BenaliDecember 12th, 2018
Read on Terminal Reader
Read this story w/o Javascript

Too Long; Didn't Read

This is an excerpt of my upcoming ebook <a href="https://laraveltesting101.com/" target="_blank">Laravel Testing 101</a>. If you haven’t read the previous chapter yet (available for free here: <a href="https://youghourta.com/2018/11/27/laravel-testing-101-where-to-start/" target="_blank">Adding Tests to your Laravel CRUD Application: Where to Start?</a>), please do so before reading this one.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - What should we be testing in a [laravel] CRUD application?
Youghourta Benali HackerNoon profile picture

This is an excerpt of my upcoming ebook Laravel Testing 101. If you haven’t read the previous chapter yet (available for free here: Adding Tests to your Laravel CRUD Application: Where to Start?), please do so before reading this one.

Now that you understand that you should be looking at tests from a different angle, and that we should test mainly controllers, you might start to ask, “… but what should I be testing exactly?”

In this chapter, we are going to answer this question and describe what we will be testing in the rest of the ebook.

But first, let’s get the demo application the book is built upon up and running.

Clone the following repo

[https://github.com/djug/laraveltesting101](https://github.com/djug/laraveltesting101)

and run the application after you follow all the steps in the readme file.

After you fire up your server/application, you should get this front page:

So far, here is what you can do within the application:

  • click on either “login” or “register” to see the login and signup pages.
  • click on “all articles” and you’ll get to /articles, that contains all the articles generated by the seeder.

  • click on “write a new article” (/new-article) and you’ll get redirected to the signup page (since adding a new article requires signing up).
  • from the “/articles” page, you could either click on articles name (example /articles/15), or user names (/users/5) to view the articles or their authors profiles.

After signing up you’d be able to view the /new-article route (which was redirecting to the sign up page when we tried it earlier without signing in)

After saving your article, you can view it, and since it is your own article, you would see the “edit article” button at the end of the page (you won’t see it on articles that you do not own).

When clicking on this button, you get the edit form of the article, where you can edit and save the article or you could delete it.

When updating the article you’ll get redirected to it again, with a success message.

But if you delete it, you’ll get redirected to the “all articles” page with a different success message.

You won’t see an “edit” button if you visit articles that you didn’t create yourself, but if you try to access the edit page of an article you don’t own via the URL directly (ex: articles/16/edit), you’ll get a 403 page.

Let’s go back to the “Write a new article” page and try to add a new article with a short title and/or a short body (shorter than 10 characters).

You’ll get an error message. And the same thing happens when editing.

So even though the application is small, there are multiple things we need to test to ensure that the application is working as expected.

And here is the list:

  1. A guest could visit and get the signup page
  2. A guest could visit and get the login page
  3. A guest could see all the articles when visiting /articles
  4. A guest could see a user profile
  5. A guest could not write a new article and get redirected to the signup page instead
  6. A user (i.e. signed up user) could write an article
  7. A user could access the edit page of her own articles
  8. A user could save the changes of her own articles and get redirected to the article page after editing with a success message
  9. A user could delete her own articles and get redirected to the all articles page with a success message
  10. A user should not see the edit button on the article she doesn’t own
  11. A user could not edit articles she doesn’t own
  12. A user could not delete articles she doesn’t own
  13. When creating an article, the article cannot have short title or body
  14. When updating an article, the article cannot have short title or body

So if we manage to automate testing the above list, we could be assured that each time we add a new feature or change a code, the application will keep working as expected.

In the next chapter, we will start writing tests with functionalities related to guests users.

If you want to follow along, and get notified of any progress with this ebook (new free chapters for instance), please sign up here: https://laraveltesting101.com/