Sunteți pe pagina 1din 12

Testing, mocking, & A2

TA: Colin Chartier


This lecture: The tools you’ll need for A2
Assignment one was all about looking at some code and identifying “code smells”
in it -- “obvious” issues.

Why do we say these code smells are bad? What are the consequences of writing
smelly code?

- Well, some of them are obvious -- it’s hard to maintain classes that have been
copy/pasted (you need to edit many files in the same way)
- Others such SOLID violations will be less obvious until A2.
Testing: An old friend from CSC108 and CSC148
There are three types of testing that you’ll encounter in your development lives:

- Unit testing (the majority that you’ve seen so far) tests individual classes -- You
might test that the display of an alarm clock works before assembling it
- Integration testing tests a “suite” of classes together -- You might test that the
clock and display parts work together correctly
- Acceptance testing (the easiest to get wrong) tests the whole thing -- You plug
an alarm clock in and test that it works (use the buttons to set the time, …) -- if it
doesn’t work, you aren’t quite sure why, but you can be certain that the whole
thing works.
Why write tests in the first place?
Let’s say you get an internship and you’re working on a team with 5 other interns
making a website in Java.

If you make a feature for the website without writing tests for it, one of the other
interns *will* break your feature.

In fact, most companies you’ll ever work for will require you to write comprehensive
tests for any feature that you write -- you’ll probably end up spending more time
writing tests than the actual code itself!
Code smells + Testing: A2
Writing acceptance tests is generally pretty easy -- you just run the whole app and
make sure that whatever you expect to happen, happens.

The problem, however, is that acceptance tests do not tell you where bugs are
when they are inevitably introduced. That’s why it’s important to know how to write
unit tests for each individual class in isolation.

Some open source projects have tens of thousands of classes. “The app doesn’t
work” does not help you! You need to know what class the bug is in!

The rest of today’s lecture will give you the tools needed to write unit tests and do
well in A2.
Code smells make it hard to write unit tests
- If you have big classes or big methods, it’s hard to write tests for them! (lots of
functionality to test…)
- If you have tightly coupled classes, it’s impossible to instantiate one without
instantiating another, so you can’t actually write unit tests (all tests would be
integration tests!)
- This is why we teach you to identify code smells.
Tools to write unit tests: Dependency injection
How would you unit test a class that looks like this?

public class ComputerScienceDepartment {


private Building building;
public ComputerScienceDepartment() {
this.building = new BahenBuilding();
}
// methods for computer science department
}

You can’t! The computer science building is tightly coupled with the BahenBuilding,
so any test of the ComputerScienceDepartment class would be an integration test
of the {ComputerScienceDepartment, BahenBuilding} classes together (and if
there’s a bug, you wouldn’t know which of the two caused it.)
Tools to write unit tests: Dependency injection
Let’s see what a refactored version would look like:

public class ComputerScienceDepartment {


private Building building;
public ComputerScienceDepartment(Building building) {
this.building = building;
}
// methods for computer science department
}

There’s a subtle change here-- instead of deciding to always make our building the
BahenBuilding, we let whoever is constructing this class *inject* a building into our
class via its constructor. This concept is called “Dependency Injection”.
Tools to write unit tests: Mocking
Why does dependency injection make it possible to write unit tests?

Remember, the original problem was that we could not instantiate a


ComputerScienceDepartment without also instantiating a BahenBuilding, so we
could not test the ComputerScienceDepartment “in isolation”, and so we couldn’t
write unit tests…

- Unit tests are (by definition) a test of a single “unit” (classes in Java)
- This means you can’t instantiate classes other than the one you are testing
- We introduced dependency injection to avoid instantiating a BahenBuilding
whenever we instantiated a ComputerScienceDepartment
- How do we actually write a unit test for the BahenBuilding, then?
Tools to write unit tests: Mocking
To write a test for the ComputerScienceDepartment “unit” (class), we’ll need
another tool: Mocking!

Mocking is used to replace a (potentially buggy) implementation of a class with a


“known good” version, which we will call a “mock”.

For our ComputerScienceDepartment example, we might have a test where a


student rides an elevator, then has access to the undergrad office -- if this test fails,
either the department schedule is incorrect (a bug in the
ComputerScienceDepartment unit), or the elevator is broken (a bug in the
BahenBuilding unit)

We can “mock” the BahenBuilding to artificially say that the elevators always work.
Tools to write unit tests: Mocking
We can “mock” the BahenBuilding to artificially say that the elevators always work.

This means that if a student can’t ride an elevator up and access the undergrad
office, the bug *must* be in accessing the undergrad office. We replaced the
implementation of the elevators with something that *always* returned “success”,
so the bug couldn’t possibly be in the building.

We’ve written a unit test!


Finally: A2
A2 will again focus on the fish tank that you’re familiar with.

We will provide you with some working FishTank code, and your job will be to:

- Refactor it to allow writing unit tests (refactoring, and using dependency


injection)
- Actually write the unit tests (using mocking)
- More details to come! You’ll hopefully be able to work on it in lab on Monday

We will evaluate you by introducing bugs in certain classes, and making sure that
your unit tests for those classes catch the bugs.

S-ar putea să vă placă și