Previous Lecture Lecture 08 Next Lecture

Lecture 08, Wed 04/14

Wed Lecture: testing aspect of team01, mocking/stubbing in Java (Mockito), code reviews and PRs

Today we’ll look at the testing aspect of the project

We’ll discuss the goal with of unit testing of isolating the unit under test so that we test only the code inside that unit (i.e. a single method), by mocking and stubbing dependencies.

This relates to the concept of dependency injection, which we’ll also discuss.

Then, we’ll discuss three practices that you’ll follow throughout the quarter:

Finally, we’ll put you in your breakout rooms so that you can try out these practices.

Dependency Injection

For testing purposes, you want dependencies to be loose rather than strict.

Example of EarthquakesController depending on EarthquakeQueryService:

Links to code:

Example of EarthquakeQueryService depending on an external API (the one from the US Geological Survey):

Links to code:

Pros/Cons of Mocking and Stubbing

Mocking and Stubbing is a widely used practice in the software industry, and definitely is an important thing to know about.

We also acknowledge that it has its limitations, and its critics:

Some pros:

Some cons:

This brings us to a concept call the testing pyramid. The following diagram is copied from the article The Practical Test Pyramid by Martin Fowler, which I encourage you to read if you are interested in this topic. The diagram itself is attributed to Mike Cohn.


(This diagram uses the phrase “service tests” where many other sources use “integration tests”, but it’s the same concept. Unfortunately, terminology in CS and Software Engineering is not nearly as standardized as we might hope for.)

Martin Fowler discusses the pros/cons of various types of testing, and of the test pyramid concept itself, but arrives at two big-picture take aways that represent something like the mainstream consensus, though individual opinions will vary:

  1. Write tests with different granularity
  2. The more high-level you get the fewer tests you should have

Point 1 says that it’s useful to write:

Point 2 says that as we move up this pyramid, there will likely be fewer tests

The reasoning behind point 2 is that lower in the pyramid, the tests are:

I would also acknowledge that:

Standup Meeting

One of the common practices when teams use the software design life-cycle methodologies known as Agile and/or Scrum is the Standup Meeting.

What happens in a standup is typically this: each team member, one-by-one, speaks and tells the team:

This last point is important.

Let’s put this in the context of today’s class meeting. I highlighted the text in support of the team’s goals above.

The specific team goal that I want to highlight in today’s standup is

So, each member may like to describe:

Blockers could be:

But they could also include things like:

As a team, I encourage you to support one another with both kinds. The team’s success depends on it.

Whatever the blockers are, during the standup:

A modififed standup for Zoom / Class (P04)

During the Zoom era, and so that the staff can help you practice with standups, I’d like to propose the following structure. This is also today’s particpation activity (P04).

  1. When you get to your breakout rooms, one person will share their screen, and point at the Slack channel for the team.
  2. Start a two minute timer (if you type two minute timer into Google, it will bring up one on the search results directly, or there are lots of fun countdown timers on YouTube as well.)
  3. During the two minutes, each person types into the Slack channel their standup summary:
    • What stage of team01 are you on? Mention the number (2.0 through 2.9), but also describe it in words.
    • What are you planning to do next
    • What blockers (if any) do you have (answer could be “none”)
  4. After the two minutes, go through and have each person unmute themselves and share their status update out loud. This may seem redundant, but there’s a purpose:
    • It’s an opportunity for the team to focus on each person’s sharing one at a time, and…
    • … more importantly to respond to each person’s sharing.
    • If there are blockers that can’t be dealt with immmediately, make a note to deal with them after standup.
  5. Once everyone has shared, standup, per se, is over. But now, deal with the blockers if any.
    • This may be a longer discussion, and it might be one where the whole team doesn’t need to particpate.
    • For example, it might be two team members going into a separate breakout room to discuss the solution to a problem.

A particular “blocker” is if the team members has made their pull request and is waiting for a code review, and for their PR to be merged. We’ll discuss that one next if time permits; if not, we’ll return to it on Monday.

Discuss Code Reviews and PRs if time permits.

Breakout rooms…