[L10 Recap eLearning video]

Test inputExpected nullfalse Test inputExpected null,0exception Design test cases for these two methods. /* Returns true if the name is non-empty and not null and not longer than 40 chars. */ public boolean isValidName(String name) { //... } /* Throws StorageException if name is not valid or if name already exists in the database. */ public void saveScore(String name, int score) throws StorageException { if (!isValidName(name)) { throw new StorageException("invalid name"); } if (Storage.isFound(name)) { throw new StorageException("already exists"); } Storage.save(name, score); } count {answer} e.g. count OR tinyurl.com/answerpost Pause video Pause the video while you answer the question.

Test inputExpected nullfalse Test inputExpected null,0exception Design test cases for these two methods using heuristics covered in Lecture 9. /* Returns true if the name is non-empty and not null and not longer than 40 chars. */ public boolean isValidName(String name) { //... } /* Throws StorageException if name is not valid or if name already exists in the database. */ public void saveScore(String name, int score) throws StorageException { if (!isValidName(name)) { throw new StorageException("invalid name"); } if (Storage.isFound(name)) { throw new StorageException("already exists"); } Storage.save(name, score); }

Test inputExpected nullfalse Test inputExpected null,0exception /* Returns true if the name is non-empty and not null and not longer than 40 chars. */ public boolean isValidName(String name) { //... } /* Throws StorageException if name is not valid or if name already exists in the database. */ public void saveScore(String name, int score) throws StorageException { if (!isValidName(name)) { throw new StorageException("invalid name"); } if (Storage.isFound(name)) { throw new StorageException("already exists"); } Storage.save(name, score); } What kind of testing are we using for each method? The first one is black box testing. The second is glass box testing.

Test inputExpected nullfalse Equivalence partitions null empty too long right size Values null “ ” /* Returns true if the name is non-empty and not null and not longer than 40 chars. */ public boolean isValidName(String name) { //... } Groups of inputs that is possibly treated differently from the rest of the input Let’s start with this method.The first thing is to find equivalence partitions.Here’s a reminder what they are.here are the partitions.Let’s pick values from each partition. This one has only one.For this one, we can pick an empty string.Note that it doesn’t have to be zero length.

Test inputExpected nullfalse Test inputExpected nullFalse “ ”False Length==41False Length==50False Length==40True Length==10True Equivalence partitions null empty too long right size Values null “ ” length = 41 40, 10, 50 /* Returns true if the name is non-empty and not null and not longer than 40 chars. */ public boolean isValidName(String name) { //... } Groups of inputs that is possibly treated differently from the rest of the input Let’s pick the boundary value,and a non-boundary value.We can do the same here.And here are the test cases. The grey ones are the less important ones.

/* Throws StorageException if name is not valid or if name already exists in the database. */ public void saveScore(String name, int score) throws StorageException { if (!isValidName(name)) { throw new StorageException("invalid name"); } if (Storage.isFound(name)) { throw new StorageException("already exists"); } Storage.save(name, score); } Test inputExpected nullFalse “ ”False Length==41False Length==50False Length==40True Length==10True null empty too long right size null “ ” Equivalence partitions Values length = 41 40, 10, 50 Now let’s take this method. Note how this method is calling the same method we tested earlier. Does this mean we need to test all those cases here again? Let’s see how it goes.

Eq. partitions invalid exists new Values Any invalid e.g. null Any existing name e.g. “existing guy” Any valid new name e.g. “new guy” name scoreany /* Throws StorageException if name is not valid or if name already exists in the database. */ public void saveScore(String name, int score) throws StorageException { if (!isValidName(name)) { throw new StorageException("invalid name"); } if (Storage.isFound(name)) { throw new StorageException("already exists"); } Storage.save(name, score); } Test inputExpected “new guy”, 0success null, -3exception “existing guy”, 5exception When picking equivalence partitions, we consider groups of values THIS method is likely to treat in the same way.For example, this method treats all invalid names the same way, irrespective of why the name is invalid.Here are the other two partitions for the name.The method treats all scores the same way, so there is only one partition for that.And here are the test cases.

/* Throws StorageException if name is not valid or if name already exists in the database. */ public void saveScore(String name, int score) throws StorageException { if (!isValidName(name)) { throw new StorageException("invalid name"); } if (Storage.isFound(name)) { throw new StorageException("already exists"); } Storage.save(name, score); } Integration tests are choreography tests. They do not test components. They test how well the assembly of components dance together. Test inputExpected nullFalse “ ”False Length==41False Length==50False Length==40True Length==10True Test inputExpected “new guy”, 0success null, -3exception “existing guy”, 5exception If Unit testing, we should use stubs for isValidName etc. We did not re-test all these test cases we used for testing the isValidName method. That is because this is an integration test. This method is integrating three other methods. We assume that those methods have already been tested and are working correctly. Our concern here is to find if they are working together correctly, as required by this method. That is the difference between unit tests and integration tests. Note that if we are unit testing this, we should have used stubs for the three methods, to isolate this method from those three. In cases like this, it is ok to skip unit testing and go straight to integration testing.

Short and simple methods /* Throws StorageException if name is not valid or if name already exists in the database. */ public void saveScore(String name, int score) throws StorageException { if (!isValidName(name)) { throw new StorageException("invalid name"); } if (Storage.isFound(name)) { throw new StorageException("already exists"); } storage.save(name, score); } Test inputExpected “new guy”, 0success null, -3exception “existing guy”, 5exception Do we really need these tests? If you think this method is so simple that it doesn’t even need testing,take it as an inspiration to write short simple methods. It can reduce the risk of bugs greatly.

/* Throws StorageException if name is not valid or if name already exists in the database. */ public void saveScore(String name, int score) throws StorageException { if (!isValidName(name)) { throw new StorageException("invalid name"); } if (Storage.isFound(name)) { throw new StorageException("already exists"); } Storage.save(name, score); } Test inputExpected “new guy”, 0success null, -3exception “existing guy”, 5exception Do we really need these tests? But avoid the temptation to skip testing. Even a broken clock looks as if it’s working twice a day. Just because the code looks right doesn’t mean it is right. Test anyway.

..s bud 1: desc: send budget deadline: Thu 22 nd September 2: desc: review buddy program deadline: Wed 21 st September Where we are… Now you should be close to a product that is at least usable to yourself. The next step is to polish it until it becomes a gem of a product. While we are on the subject of polishing gems, let’s see this video of a traditional gem polishing technique.

1. Aim to create a gem you will be proud to wear 2. Polish, check, polish, check, polish, check,… 3. Sharpen your tools once in a while Three things to remember. One: Aim for a gem, not a brick. Two: Tweak the product a little and try it out yourself. Rinse and repeat. Three: Notice how the gem polisher sometimes sharpen his tool instead of polishing gems. Likewise, spend some time improving the way you do things and the tools you use. That can pay dividends in the long run. Remember, the product is not the main thing. What you become is more important.

Today’s theme Nearing completion. Gearing up for bigger projects. ? Today, we are going to learn a few things that will prepare you for bigger projects.

Estimate the total statement coverage of this method for these three test cases. a) about 50% b) about 80% c) 100% cover {a|b|c} e.g. cover c Test inputExpected “new guy”, 0success null, -3exception “”, 5exception OR tinyurl.com/answerpost Pause video Before that, you can try this question.Pause the video while you think of the answer.The first test case executes these lines. The second test case executes line 2 in addition to the ones executed previously. The third test case does not execute any more new lines. Therefore, the total coverage is about 80%.