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.

10:10 It’s hard to say how many bugs our testing has caught, or how many more we’d have if we weren’t testing. If we do find a bug, chances are it’s a problem with design or Javascript, and not Ruby; because we run many more tests on our Ruby code.

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 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

24:35 We use Karma for testing Javascript. Karma is a file watcher, and will run your tests on any browsers you choose.

25:15 We’d like to have a single test watcher running locally. It’d be so much nicer if all our tests ran inside of Guard, including Javascript tests.

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.

Show Links:

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!)