Testing Principles

Testing sounds stupid when you first hear about it. It’s like why would I test something when I know it’s absolutely fucking correct. My application doesn’t need testing, I’m a great coder. Well, I used to agree with that, but now I’ve seen the light. Like a sinner converted to Moronism, I’ve seen the light.

What amazes me about testing the most is this… When I write a test, it’s basically exactly what I would do, in reverse.

Not Testing…

Write a method, open up rails console, test it to ensure it does what you want

Testing

Write a test to ensure the method does what you want, write a method

See, you even get to skip a step of opening console. If someone would have just told me I was already testing my applications, I would have been happy, and maybe excited to test the “real” way. See, my misunderstanding of testing was… I told myself… I ain’t testing, fuck that. But in reality I was testing my app by opening up the console and testing the method I just wrote to ensure it did what I want. Everyone tests their application, it just so happens that tests disappear when you use the Not Testing method. See you test that method manually. But once you understand the basics of testing, it’s just as easy to write a test as it is to open console and type it out. The first method would be great if there were no side effects, that method would work forever. But shit gets coupled together, life gets hard, and so you might as well write tests that last, and that’s by opening up your specs and putting stuff in there.

Principles of Testing

You can learn Rspec. You can learn MiniTest. But if you don’t understand the principles of testing, it doesn’t matter. You will be able to write tests, but will the tests fucking actually test the right things? When you understand the principles, then you can apply those principles to any language, any testing framework, etc. When you understand the principles, then you can look at a framework and say, that doesn’t do what I need it to do. Then you can either write that functionality in or find a different framework… rather than just being like what the fuck does everyone else do?

Principle #1: Anytime data is changed, it needs a test to prove that. If… within your method, you edit a string, mutate it in any way, you need a test for that.

def sub_underscores(a_string)
  a_string.gsub(/_/,'')
end

# test
describe "#sub_underscores" do
  it "should remove all underscores" do
my_string = "derp_derp"

expect(sub_underscores(my_string)).to eq("derpderp")
  end

  it "should remove two underscores" do
my_string = "derpity_derp_derp"

expect(sub_underscores(my_string)).to eq("derpityderpderp")
  end
end

Principle #2:

More Ramblings…

If you encounter a nasty method. One without tests, one that does multiple things, one of those methods that is amazing it works and the only reason you think it works is because the customer hasn’t complained…

Well, the first thing to do to start testing it, is to make an assertion. Once you make an assertion, the test will tell you any missing inputs. Then when you put in the required inputs, you’ll get out the expected answer. Then you can input that answer, into your test as the correct answer, and it should be the first passing test! Damn, that’s pretty nice.

Method Naming…

Call methods what they do, not how they do it.

So above rather than sub_underscore, I really should have called the method, remove_underscores.

Refactoring… is…

Find code that does a sub-task and give that code a name…

code smells large methods, two levels of abstraction

Post Content