This week, we’re talking about testing: what testing is, the different kinds of tests we run at CodePen, and why they are important.
What kind of testing do we do at CodePen?
2:28 Mostly unit testing. You have a pre-defined set of inputs, and you test the outputs from the code, and figure out if it returns the right thing. It seems simple, but often things don’t happen the way you assumed.
Don’t assume you know what is going to happen. Test it.
5:49 We’re moving further toward full testing; we don’t write any code at all unless there is a test for it.
6:15 What is the “Happy Path”? We use that phrase here at CodePen, it just means “what we absolutely expect users to do, and how it works in our mind.” So hopefully there aren’t any errors; the request was authorized, the database was available, nothing happened to cause an error state for a user.
Why did we start testing more?
7:20 We didn’t do a lot of testing when we first started, but we got better at it and started doing it more as time went on and our code became more complex.
When we started, we thought that we didn’t have time to write tests. Now we know that writing code without tests end up taking a lot longer.
The benefits of Continuous Testing
We used to worry about breaking things when pushing updates, but now that we’re testing our code more, we’re more confident in the changes we push live.
14:50 If you’re really hardcore about testing, you should try Continuous Integration. You push code, tests get run on the code, if the tests pass, the code goes live.
We’d love to get our testing to a place where when we push code, we immediately get feedback from the server if there was a broken test.
17:57 Continuous testing would also force us to make sure our code works on another system. The code will be running on systems different from our local environments, so we’d have a better idea of how our code runs in other environments.
Our testing workflow
20:02 Systems like Guard (file watching) makes it easier to run tests on everything – automatically – anytime you change a file.
20:57 Our testing stack is:
- RSpec – the domain specific language for testing itself. Example: “Expect user.name to = tim”
- Spring – runs in the background and keeps the files required for the rails system running
- Guard – watches the file system for file changes
- Factory Girl – Allows you to create a default user with required properties pre-set
- Database Cleaner – a set of strategies for cleaning your database in Ruby
Why you should be testing
Tests really shine when the level of complexity is extremely high, when there’s just too much to keep in your brain.
27:30 You should definitely test when you’re developing your application. We’re reminded of this every time an email comes in that has a bug that could have been caught by testing. We’re getting better at this, often times, support bugs will lead to new unit tests in our stack.
29:12 If you aren’t testing yet, start digging into testing and making it a part of your practice. You’ll thank yourself later.
- Factory Girl
- Database Cleaner
- Jasmine Unit Testing Framework
- Phantom JS
If you’re enjoying this show, please take a minute to leave us a review in iTunes. We really appreciate it, and thanks to everyone who has already left a review! (We read all of them!)