7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial
FREELessons: 17Length: 2.7 hours

Next lesson playing in 5 seconds

Cancel
  • Overview
  • Transcript

2.2 The Signup Process, Part 2

This is part two on providing a sign up mechanism for our application. We were trying to figure out how to create a user's table. Let's see how we can do that. Let's go ahead and go to the Rakefile here and create a new task to migrate the database. We're gonna pick up on the same thing that we had in the test helper. So we use ActiveRecord::Base.establish_connection with the adapter and database in this specific case. And we can run rake db migrate. Now as far as the migrations go, we should provide a folder where the migrations are located. I'm going to change this to be lib then api then migrations. This will mean that from the Rakefile, we should go to the root of the project, then lib/api and migrations there. From here, I'm going to rush this a little bit. Let's create users.rb file. And open it in a new tab, and inside we'll just type in a standard rails migration. So, CreateUsers will inherit from ActiveRecord::Migration. Inside I am going to define the change method, which will in turn create the users table. So create_table users will pass in the t argument to define, for example, a string for the email. And we're going to let that be null. Then de-encrypt the password and finally some timestamps. I think this is also pretty good to be made available. The ID column will also be implemented automatically. And from here we can type in bundle exec rake db migrate. Okay, you can see that the active_record class isn't there. So let's go to our Rakefile and require active_record, like so. Okay, let's see if this now works. Let's run the migrate task again, and there you go. The table called users is now implemented, and now we should be able to run the tests, no problem. Okay, there you go. We have all three assertions running. Two of them are the test ones. And the other one regards our users so let's see where we were in the first place. There you go. We were asserting that the encrypted password would be greater than 32 characters. And it is because the SHA1 method digests our password into a bigger string than 32 characters. Okay, let's move on to the remaining. You can see here that it doesn't allow the password to seen again. And because of that, I can just run the tests, and the password method doesn't even exist. That's safe to say that we just don't need this at all. I'm just going to straight up delete it. It doesn't make any sense, so we can just move on to the next one. We want to save the user in particular in the way that it will have an ID. I've deleted the skip method so that it runs. So I'm going to run it. And it also runs. Remember, if I don't save the user at all, that test will fail. We expected nil to not be nil, only when we save the user, we will have the ID added into it. Let's move onto the next one, and this one should be passing as well because we added the timestamps variable In the create_table instruction. So when running the tests now, they will pass as well. There's only one test left and that is to assert that the service returns an ok status. If we run the tests now, they will fail because we expected an ok message, but we got nil. In line three, you can see that the status method exists as an attr_reader. So, at the end, we will just type in status equals ok. In fact, we can type in if user.save, then we will pass something like this. Let's run the tests now. And they pass. As far as the sign up goes, this is what we should be doing. We're not going to cover the alternative cases because they would take just too long. And the protocol is already so big, we need to focus on what's really important. After building the entire mechanism for signing up, we can now jump straight to implementing an API front end to consume this sign-up service. Lets do that, jumping to the next lesson.

Back to the top