Build an Appointment Booking System With Laravel
This episode is for members only

Sign up to access "Build an Appointment Booking System With Laravel" right now.

Get started
Already a member? Sign in to continue
Playing
12. Writing tests for schedule availability

Episodes

0%
Your progress
  • Total: 4h 49m
  • Played: 0m
  • Remaining: 4h 49m
Join or sign in to track your progress
01. Introduction
01. Introduction and demo
9m 48s
0%
02. Fresh project with Pest
2m 14s
0%
02. Core functionality
03. How we build up availability
7m 55s
0%
04. Employees and services
7m 39s
0%
05. Employee schedules and exclusions
7m 53s
0%
06. Setting up appointments
5m 34s
0%
07. Working with date periods
10m 4s
0%
08. Iterating over requested days in a period
4m 51s
0%
09. Adding schedule availability
15m 38s
0%
10. Subtracting employee schedule exclusions
7m 53s
0%
11. Excluding time already passed
2m 57s
0%
12. Writing tests for schedule availability
19m 50s
0%
13. Generating slots
14m 47s
0%
14. Building the service availability generator
7m 5s
0%
15. Adding employees into slots
9m 44s
0%
16. Removing empty slots
4m 42s
0%
17. Removing slots with booked appointments
6m 44s
0%
18. Using a custom date collection
3m 34s
0%
19. Writing tests for service availablity
18m 42s
0%
03. Building the booking UI
20. Base layout and Tailwind setup
5m 5s
0%
21. Listing employees
5m 42s
0%
22. Listing services for an employee
8m 30s
0%
23. Scaffolding the checkout
8m
0%
04. Building the availability calendar
24. Installing Alpine.js
3m 15s
0%
25. Installing and using easepick
7m 31s
0%
26. Disabling unavailable dates
8m 43s
0%
27. Showing available slots on the calendar
9m 54s
0%
28. Requesting available slots
4m 41s
0%
29. Fetching available slots
9m 36s
0%
30. Displaying and selecting a slot
5m 46s
0%
05. Booking appointments
31. Hooking up customer appointment details
5m 17s
0%
32. Disabling future steps
2m 43s
0%
33. Storing an appointment
14m 43s
0%
34. Handling appointment collisions
8m 1s
0%
35. Redirecting to a confirmation page
2m 55s
0%
36. Building the appointment confirmation page
5m 40s
0%
37. Cancelling an appointment
5m 30s
0%

Transcript

00:00
Okay, let's go ahead and write some tests for the functionality that we've already built, and we'll come back to this to add more later when we get on to our slot generation.
00:08
So I've written out here a list of the tests that we're going to build. There are more that you could probably add to this, but this is going to give you a really good idea as to how to test this kind of functionality with date periods within Laravel applications. So the first test is going to be that it lists the correct employee availability. That's just going to be a general
00:25
test just to make sure that it's giving us out the right availability for that general availability that a user has. The second test that we're going to write is that it accounts for different daily schedule times. So if I don't work on a Monday or a Saturday and Sunday, we shouldn't see any availability for them days. The second one is it doesn't show availability for our scheduled
00:46
exclusions. So for our holidays that we've booked or any days off, whatever we need to do. And the last one is it only shows availability from the current time within an hour in advance, which is what we just did in the last episode. So yeah, there's a few more that we could add, but let's get started with these and we can add more later if we need to. Okay, so to create this
01:06
test out we can just use phpArtisanPestTest and we're going to put these in a bookings directory and I'm going to call this schedule availability test. Kind of makes sense, we'll name it what the class is. Okay, I'm going to copy these over to that schedule availability test. So let's open that up and let's just pop these at the top here and we'll comment them out. Okay, so let's work
01:29
on the first one. Lists the correct employee availability. So we don't need these and the very first thing that we're going to do, and this is really important with tests that deal with time, is use that carbon set test now method. So the first thing that we'll do is use set test now and we're going to set this to just any date. It doesn't really matter what we choose here.
01:52
So I'm going to say carbon parse and we'll say the first of January and we'll say 2000. I like to keep the dates when I'm testing way into the past just so we have a really simple day that we can work with. We can also say things like the first Monday of January, but we'll just keep it at the first. Okay, so the next thing we need to do is create an employee.
02:14
So we already have our factory, so we can just use employee factory and we need to add some schedule availability for this employee. So we can create that out in between that with a factory. We can say that it has a schedule, so we can use that schedule to grab the schedule factory and we can set some states inside of here. So let's just remind ourselves of our schedule factory.
02:40
Remember all of these are implied that we work every single day, which is fine. We can always modify them within our tests. What we're interested in doing is setting the specific state for the starts at and ends at. So let's say starts at now start of day and we'll say ends at and let's just say now at one year end of day. So we're just going to give that employee a year's
03:07
worth of schedule and of course remember they work nine to five every single day, but if you wanted to tweak them within your tests you would just pass that data directly into here. Okay, so we've got an employee. What else do we need to be able to test this? Well, we need a service because that service needs to be passed in as a dependency. This is going to be pretty straightforward. We just want
03:26
to grab our service factory and create that out specifically with a duration of 30. Okay, so next thing to do is just create out our schedule availability class. So let's go and just call this availability, new up our schedule availability class, pass the employee in, pass the service in and then say for period and let's choose a period. So we'll say now start of day and let's say now
04:01
end of day. So we'll just keep this really, really simple and say that we want to see the availability just for today. Okay, so I'm just going to go ahead and run pest in here just to make sure that everything works and of course it doesn't here. So we've got no such table employees. Of course what we need to do here is make sure that we're running our migrations every single
04:17
time we run this test. So let's head over to our pest config here and yeah we just want to make sure we enable refresh database that will run our migrations on our sqlite database in memory and that will only apply to our feature tests which is what we're writing here. Okay, let's go ahead and try that again. Run pest and yeah works nicely. So what's happening here is obviously
04:39
we're starting to like die and dump stuff within our code. We want to clear that up and return something so we actually have something to test. So let's head over to our schedule availability and at the moment we are iterating over these and dying and dumping on them. Let's just return this periods. So we want to do all of that stuff that we're doing here and then just return them
05:00
periods. Okay, let's go and just run our test again and there we go. Of course we get a risky test because we haven't performed any assertions. Now what we want to do here is grab if we just die dump on availability and run pest you can see that what we get back is a period collection. We want to grab the first period here or the current period so we do that using current. We can
05:23
also go forward into the next period as well which we will look at in some of these other tests that we write. So let's go ahead and run pest again and you can see that we get the first period here which now makes it super simple to check if the schedule is correct and you can see it is correct here. We know it's correct because we've already tested this just in the browser but we can now
05:43
start to assert on the current period. So I'm going to go ahead and switch this over to an expectation on that current period and now we can just fill in the rest of what we need to do. So we're going to say starts at which is a method on each of them periods and we want to make sure that this starts at nine o'clock. So we'll grab the current date and time it doesn't really matter too much and
06:04
we'll say set time from time string and we'll say we want this to start at nine o'clock and we want that to be true. So to be true on this so starts at is a method on the period which will check if it starts at what you've given so this will either return a true or a false and of course we're just expecting that to be true. Okay let's go ahead and just run pest and yeah sure enough that passes we
06:30
know that for the availability that we have attached to this employee it's always nine to five because that's what's set up in our factory so we know that there it should start at nine. Now we can continue to chain on to this and check the ends app so we can do exactly the same thing here and we can expect that to be true as well and let's run pest and yeah of course so it doesn't
06:55
end at nine o'clock it ends at 16 30. So let's go ahead and run this and there we go great. So now we know that if we tweak something in here on the schedule availability like we get rid of the if we just check one of the methods that we added in here for example this sub minute off the duration of the service we know that that's going to fail now because we expect it to be at the
07:27
ending of the day but not right at the end of the day we need to take the service into account. So we know that that's the case because the service that we chose here has a duration of 30 but if that changed then the value would change here as well. Okay so that's one of the easier tests we've got that one out of the way and done with let's look at that it accounts for different daily
07:45
scheduled times. So i'm going to go ahead and grab the test that we've already written and i'm just going to paste it down and i'm going to get rid of these expectations here. So we want to do pretty much the same thing here we still want to set the date here but we want to choose monday january 2000. So what that will do is it will pick the first monday of january in 2000 because we are
08:06
checking now if we just go up to the top accounts for different daily scheduled times let's change the name of the test this needs to be for monday specifically. So now we can start to dive into the details of the schedule and make sure that these work properly. So we're going to in here explicitly say monday starts at and we're going to set this to say 11 o'clock monday ends at
08:36
we're going to set this to say four o'clock doesn't really matter what we choose here and we'll do the same thing for tuesday as well so we've got another date in there that we can work with so let's change that to tuesday ends up okay so let's change these over to the normal times nine till five and we should be good to go so we create a service that's going
08:56
to be exactly the same we mu up our availability just inside of here our availability checker and now we want to check first of all the monday and then we want to check the tuesday so we want to check the monday is different to the tuesday because they're the times that we work how do we do this well the first thing that we can do is just exactly what we did before we can grab the
09:19
current period in our availability and we can check the starts at so let's say starts at set time from time string and that should start at 11 and we'll expect that to be true and let's run pest and yeah sure enough that passes and it's all good so we can also do the same thing for ends app and that needs to be i think let's have a look at what we chose
09:48
four o'clock so that should end at 15 30 and let's run pest there we go great so we know that that works but this is just one day now again if i just die dump on the availability you'll see you'll see that we get a period collection of periods in here and we have got yeah we've got just got one period so let's adjust the time that we're looking at so this will be add day
10:20
end of day so we're looking at the end of tomorrow and if we run pest again we should now have two periods in here so we've got two periods this is the 11 till 330 and then the next period is going to be 9 till 6 to 4 30 so exactly what we would expect and what we've already seen but the question is how do we get the next period what we do is just on the period collection that's being returned
10:48
we just say next now a little bit of background around why this works if we open up the period collection you'll notice that it has the array access iterator and countable implementations on it and it has an iterable implementation so this is pretty much what you would expect in any kind of iteratable implementation in php and we can just rewind we can go back we can go next whatever
11:13
we need to do so we say we'll go next and then if i die dump on availability current that will be on the next day so we've gone to the next day technically and then when we grab current this will now show that next day great so now we can assert that the first available day is at these times and then we can assert down here that the next availability is completely different so again
11:37
just to save time we can grab the expectation here and we want to make sure that the next day starts at nine and finishes at 4 30 let's go ahead and run our tests and yeah this doesn't work just because we need to add a day onto here because the date and the time need to match so let's do the day increment here and we are good so now we are confident that the monday and the
12:07
tuesday with having different schedules come up at the right schedule times inside of here perfect okay so we've got accounts for different daily scheduled times now we are going to work on doesn't show availability for scheduled exclusion so pretty much the same thing but what we want to do is just add an exclusion in when we go ahead and create out that user and that schedule so
12:29
let's go ahead and just pop this down here we can grab any one of these tests of course we could create helpers to just tidy this stuff up but i'm going to be super explicit for each of these and let's look at just getting rid of all of these expectations here let's change the name of the test over
12:51
and then we'll go ahead and add in an exclusion at the same time okay so let's start by just setting the day to the first of january we've got our employee here with our schedule i'm going to get rid of these because they're not really interesting to this test but what we want to add onto the employee is a schedule exclusion as well as the actual
13:12
schedule so let's go ahead and add in a schedule exclusion inside of here exactly like we did for the normal schedule and we can do exactly the same thing and set the explicit state for the start and the end that date so let's say that this starts at we'll say now and add a day and start of day so basically the start of tomorrow and then we'll end it at the end of tomorrow
13:40
so basically as far as our test is concerned we want to check if we have tomorrow off so let's go and make this a little bit more interesting actually so i'm going to add another schedule exclusion in here for lunch so let's say that we want to say today set time from time string at 12 o'clock we want to add lunch till one o'clock okay great so we've
14:08
got tomorrow off and we've got a lunch break today between 12 and 1 so the service is going to remain the same it doesn't really matter and for the actual check itself let's just keep this for today and tomorrow okay so let's start to add our expectations i'm just going to run past just to make sure we've set everything up correctly and it looks like we have so let's go ahead and
14:31
start to check so we're going to expect the schedule availability that we've just defined for the current period which will be for today we want to say starts at now and we'll set the time from the time string again we expect this to start today at nine o'clock to be true so it should start at nine but it should end before lunch so let's just say ends at
15:06
let's say 12 it might not be 12 it might be 11 59 but let's just check this anyway so let's go ahead and run pest and yeah sure enough it doesn't work i have a feeling that we'll have put that to 11 59 because the next available period will be 12 dead on so let's go ahead and run pest and there we go it works so we know that our availability from today is from
15:27
nine to twelve but our availability for today should also be from one onwards so what we need to do here is because the way that the period collection class works is it chops this up into individual periods even if they're within the same day we still need to go ahead and go to the next period before we check that so we go to the next period and then we're going to expect after lunch
15:50
to be available as well so this should be from 12 up till 4 30 so go let's go ahead and run pest and yeah it failed so let's just check what we can do here is just die dump on availability and current and let's run our test and just see what we get so one o'clock yeah of course it should be from one o'clock that's my mistake we have 12 to one that's our break let's run our
16:15
tests getting rid of that die dump and yeah we're good so we know that that lunch break exclusion has been taken into account so now what we can do is go into the next day so availability and next and basically we know that as part of this test we have set up an exclusion for tomorrow all day so we're just off all day even if this was nine till five it would still exclude it from the list
16:44
now when we looked at this earlier in the browser it just got rid of it so what we can't do is we can't assert that the start sat of a period that doesn't exist is a specific date and time so if we just die dump on availability and current what we get is an undefined array so what we need to do here is expect availability valid which will check if that's a valid period
17:12
or not to be false so that's not a valid period because we have excluded it completely and it doesn't exist because we have taken the entire day off so let's go ahead and run our test and yeah sure enough it works great okay so the last test that we're going to write is it only shows the availability from a current time within an hour and advanced so let's go down and start to build
17:34
this out again i'm just going to copy one of these tests that we've already got yes these are really really chunky but i think reading down them makes a lot of sense so let's just grab one of these pop it down here and we'll change this over great so let's pull this into our test name and the test date here is really important because this is what we are after we want to
17:58
set a specific date like this but we want to set a certain time so let's say that it's currently 9 15 so let's set that properly we shouldn't see the next appointment available until 10 o'clock because we know that we are pushing this to the end of the hour so let's go and get rid of these days here because we don't need them we've got our employee with the starts and ends at we've got our
18:22
service we've got our availability here from the start of the day till just the end of the day we don't really care about any other days and we will get rid of our expectations in here as well okay let's go ahead and just run pest to make sure everything's set up properly and it is and let's add in our expectations for this this is going to be very very simple because
18:42
we just want to check that the current availability starts at so let's come down here and say starts at now set time from time string and we know that we want it to start at 10 o'clock and we want that to be true to be true and we're done okay great so we have a current time of 9 15 and we know that from our testing earlier the next available appointment should be a 10 because
19:13
that time has already passed and sure enough it works now you could adjust this even further if you wanted to so for example if you wanted to check that this was really later on in the day like 12 15 of course the next available appointment would be at one o'clock and i think that for that test makes a little bit more sense to push the day further into the day so we
19:32
can see what we're talking about okay there we go there is our test for our schedule availability quite verbose but hopefully you've learned a little bit about testing within these periods and also with our date times it's really really important that we test this time stuff and do it really really carefully

Episode summary

In this episode, we're diving into writing tests for the schedule availability functionality we built previously. The focus is on making sure our Laravel application's logic for checking when employees are available is rock-solid and ready to handle different real-world scheduling scenarios.

Here's what we do step by step:

  • First, we review the core tests we want to build—like making sure the system lists employee availability correctly, accounts for unique daily schedules (e.g., not working weekends), handles exclusions (such as days off and holidays), and only shows slots that are available from the current time plus one hour onward.
  • We then get hands-on: generating a new Pest test, setting up our test environment to ensure database migrations run properly, and then starting to write detailed tests, each time checking assertions around start and end times for different periods.
  • We pay special attention to creating scenarios where employees might have different working hours on different days, scheduled time off (like lunch breaks or full days off), and making sure our code properly excludes or splits availability based on these exceptions.
  • Throughout, we use Laravel's Carbon::setTestNow to freeze the date and time inside tests so they're reliable and predictable.
  • We test traversing through periods—like checking today, then jumping to the next period (e.g., tomorrow)—and show how to assert that the system reacts as expected when a whole day is excluded.
  • At the end, we check that future appointments only show up if they're far enough ahead of the current time (e.g., at least an hour later).

Overall, this episode is all about translating our scheduling logic into robust automated tests—it might be a bit verbose, but it's super practical and leaves us confident that our scheduling system behaves exactly how we want it to, even as things get complicated!

Episode discussion

No comments, yet. Be the first!