We covered a few more Rails testing essentials on Monday morning before spending the rest of the day working on our SeatYourself (clone of OpenTable) app.
Unit tests, functional tests, feature tests
There are three different types of testing in Rails:
- Unit tests, which test to ensure our models (data) are working and are associated correctly,
- Functional tests, which test our controllers and the methods inside them to make sure the small cogs in the large Rails machine are working correctly, and
- Feature tests, which do things like fill out forms and click submit or login buttons for us to make sure they’re working for the user.
Why testing is important
Writing software tests saves developers time in the development process — this seems like the most obvious reason to me why we would spend a bunch of time writing out tests to do check that models, controllers, and features are working correctly. It is tiresome and time-consuming to fill out every form on your site every time you change a bit of code, and tests can automate this. Testing is also important for checking functionality that is not visible to the user but could prevent a program (or the entire app from working). Finally, Rails has a built-in testing directory (ActiveSupport::Test Case which inherits from MiniTest, the Ruby testing language) to help us write tests, and we should do what Rails suggests because it is almost always right.
So, as tiresome as it might seem to some at first, testing is a pretty vital part of development and you should learn it early and practice it often.
This is a fun concept whose name pretty much describes what it is. Test-driven development basically means writing a small test for each functionality and feature in your app, running that test (which will fail), building that functionality or feature, and running the test again (which will pass this time). I watched one of our instructors build out part of the SeatYourself app this way and it seems really tiresome and difficult… but I can understand why someone would build something this way. I just won’t be for a while.
A few things to remember
- Semicolons EVERYWHERE after you’re finished an idea — except at the end of function definitions and if/else statements — or else the JS interpreter will add them for you and you’ll get weird bugs
- Always use “var” when creating a new variable (unless you want it to have the scope of all your JS code)
- We name functions, methods, variables, and objects in camel case, with a lowercase first letter (like this: myFirstFunction).
- There are five kinds of data types in JS: number (1, 2, 3, 4…) , string (“Oh HAI”, boolean (true or false), undefined (the absence of a value), and null (value that is explicitly not a value).
… could be written with jQuery like this:
We continued with jQuery on Friday and learned about closures and animations. Did you know that you can tell your computer to do this:
… and it does this?
I didn’t! But I’m so excited to put some of this to work next week. There is a lot to internalize this weekend.
Until week 6.