Transcripted Summary
So far, we just looked at creating a customer with valid details, and one of the things that you want to do is to start to think about whether or not this class is designed by contract or designed defensively.
We might be tempted to start to write a lot of negative tests around this particular scenario, but if there's a contract in place, then we need not write negative tests. But we'll assume for now that we're designed by contract, and we'll just try to write another happy pass scenario for a different function.
Let's focus on maybe updating information. Because now we've checked that we can store, but can we actually update a customer that has made a previously stored with new details?
The first step is to write our test scenario.
/**
* The system should be able to update customer information using valid data.
* Scenario:
* 1. Given I create a new customer named Mickey Mouse.
* 2. When I update Mickey's customer information with Minnie's information.
* 3. Then Minnie's information should be stored in the system.
*/
@Test
public void updatingCustomerDataWithDifferentValidValues_StoresNewValues() {
// Given
Customer customer = new Customer("Mickey", "Disneyland", "Mickey@Disneyland.com");
// When
customer.updateName("Minnie Mouse");
customer.updateAddress("Disney World");
customer.updateEmail("Minnie@Disneyworld.com");
// Then
assertEquals(customer.getName(), "Minnie Mouse");
assertEquals(customer.getAddress(), "Disney World");
assertEquals(customer.getEmail(), "Minnie@Disneyworld.com");
}
}
But let's think about this — we want to be able to make sure that customers can update their information.
And so, we can say,
- “The system should be able to update customer information using valid data.”
And so, we can write our scenario. We can say,
"Given I create a new customer named Mickey Mouse.’”
“When I update Mickey's customer information with Minnie's information.”
“Then Minnie's information should be stored in the system.”
And so, we have our high-level scenario.
We're just going to initialize Mickey Mouse again, and then overwrite his information with information from Minnie. And we should make sure that Minnie's information is actually persisted instead of Mickey's information.
And so, one of the things that you'll notice right away is that there seems to be some repetition between this task in terms of the set up, and our new task. And there's ways for us to handle that repetition, but we're not going to do that just yet. We're going to re-factor this later and show you some other constructs that help you to do a one-time set-up, or an each-time set-up and tear-down, to help you reduce some of the redundancy if you want to set up your test data file.
But for now, let's just continue to focus on getting the hang of writing these tests.
So here, you have your test attributes (@Test), and then outlet public void.
And now we need to give this test a name, one that’s descriptive.
So again, you want to think about this scenario and the expectation.
- And so here —
updatingCustomerDataWithDifferentValidValues_StoresNewValues— right?
You want to make sure that the information is different and that it stores those new values. And so, that's pretty indicative of what we're trying to achieve.
Now we can start to implement our “given”.
- And so here, we will then again get our customer, Mickey, Disneyland, and the same email —
Customer customer = new Customer("Mickey", "Disneyland", "[Mickey@Disneyland.com](mailto:Mickey@Disneyland.com)");
Now we have our “when” portion which is a little bit separate from that set-up.
Because now we're going to update Mickey's information with Minnie's information.
So, we're going to say
customer.updateNameand we're going to put “Minnie Mouse” in there.Then we're going to do
customer.updateAddressand let's assume that instead of Disneyland, Minnie is living in Disney World this year.And then
customer.updateEmailand we'll put Minnie's email... Disney World.
So, cool. Now we have our input actions where we actually do our update.
Now the only thing left is to verify — our “then” portion.
And so here, we're going to
assertEquals(customer.getName(), "Minnie Mouse");And we're going to
assertthat the address is “Disney World”.And then
assertthat the email has also been updated.
And so there, we now have our second test.
One thing that you'll notice, if you recall from some of the guidelines, that it seems like we're doing quite a bit more. Because this test is a little bit more involved, in our statements we have three things that we're updating, and then we're checking three things
And if you're paying attention to the guidelines, you might be saying, "Well, I thought we were only doing one thing at a time." Well, the thing with that is that you have to think about your level of extraction and what your unit really is, and the behavior.
Here we're testing the different behaviors of this class and one of the behaviors is that it has this function of updating information.
And so, while it is true that we could have done a single test to just update one field, it is a lot easier to think of this behavior as a whole and check that all fields are getting updated in one. It doesn't mean that we're doing three things. It just means that we're doing one thing that is more of a higher level of extraction.
And so, let's run our test, and make sure that our test is passing. And so here, the update tests seem to pass.
Remember, you want to make sure that you maybe make some adjustments and test each and every one of these to make sure that it is verifying exactly what you think.
So, if we make a modification and put that space out of there, then it should have a failure.
And so here, we can see that we have our first set of unit tests. They're pretty well-documented. They're very self-documenting. They test one thing at a time. The names are descriptive. We've checked them to make sure that they pass, and that they fail if something is wrong.
So, it looks like we're good for our first set of tests.
Resources
Quiz
The quiz for Chapter 4 can be found at the end of Section 4.4
