Where to Test FunctionalityWhere to Test Functionality

CSC/ECE 517, Week 9CSC/ECE 517, Week 9

How do we decide How do we decide … … where to test functionality?where to test functionality?

Rule #1:Rule #1: Unit tests should be fast.Unit tests should be fast.– Tests that access a db are not fast. Tests that access a db are not fast. – Therefore, anything that accesses the db in a Therefore, anything that accesses the db in a

unit test should be mocked and/or stubbed.unit test should be mocked and/or stubbed.

Rule #2: Test functionality in only one Rule #2: Test functionality in only one place.place.– Functionality that is tested in the model via Functionality that is tested in the model via

unit tests should not also be tested by unit tests should not also be tested by functional tests.functional tests.

How do we decide (cont.)How do we decide (cont.)

Rule #3: Don’t test RailsRule #3: Don’t test Rails– It’s not your responsibility to make sure It’s not your responsibility to make sure

that Rails is behaving according to its that Rails is behaving according to its specifications. specifications. Thus, don’t test actions like …Thus, don’t test actions like …

making sure that an object that has just making sure that an object that has just been saved can be accessed;been saved can be accessed;

making sure that creating an object causes making sure that creating an object causes the object count to rise by 1.the object count to rise by 1.

An example An example Here is code (it could be Expertiza code) for Here is code (it could be Expertiza code) for testing that a team can be created.testing that a team can be created.

def test_add_teamdef test_add_team    team = Team.new    team = Team.new    assert team.save    assert team.save  end  end

Why doesn’t this test do anything useful?– It tests that an object can actually be saved.

That’s Rails’ job.– It is saving a blank object to the db. That

probably violates validation constraints that assures that the team has a non-null name, for example.

What should we test?What should we test?When a team is created, we'd like to know – that Team.count increases by 1,

– that the "parent" of the team is a Course or an Assignment.

Should the model test these things?– Team.count increases by 1?

No, that’s just testing that Rails works.

That the parent is a particular object type?– No, the parent is set up within the test itself, so

it will be whatever type the test created.

What What shouldshould we test? we test?That a team name is unique within the course or the assignment.– This can be done by the shoulda gem, which

can assert that Team validates_uniqueness_of :name

That a team cannot add a member if its size is equal to max_team_size.

The Rails testing pyramidThe Rails testing pyramid

These problems can arise during These problems can arise during testing.testing.– Brittle tests … test “too much” about an Brittle tests … test “too much” about an

applicationapplication– Tests that run too slowlyTests that run too slowly

What to do?What to do?

Testing levelsTesting levels

The throwaway testThe throwaway test– When you do TDD, you should write lots When you do TDD, you should write lots

of tests.of tests.– But do you need to keep them all?But do you need to keep them all?

Service-level testsService-level tests– Move testing away from the UI.Move testing away from the UI.

Functional tests Functional tests unit tests unit tests

– Common app components can be tested Common app components can be tested by common tests.by common tests.