Got a YouTube account?

New: enable viewer-created translations and captions on your YouTube channel!

English subtitles

← Adding Tests To Your App - Developing Scalable Apps with Java

Get Embed Code
4 Languages

Showing Revision 5 created 05/24/2016 by Udacity Robot.

  1. Now that you've got significant functionality working in
  2. your application, this would be a good time
  3. to add some unit tests. In the lesson
  4. three folder, of the code that you downloaded from
  5. Udacity's GitHub, you'll find the test folder. This
  6. folder contains tests that are applicable up to the
  7. end of lesson three. Basically, tests for the
  8. profile functionality. Probably can't see, but we've got,
  9. we've got So go ahead and copy the test folder into the
  10. SRC source folder where you have your projects, the Conference Central. So you
  11. can just drag and drop it. There it is. Now I just want you to go ahead
  12. and delete the target directory in this folder. Whenever you
  13. run your project, or you run it on Dev Server
  14. or you deploy it to appspot, the output from the
  15. build all goes into the target directory. And it gets,
  16. it'll get recreated if you delete it. And sometimes the old
  17. build and the old output files and the new output
  18. files don't work well together. So, when in doubt, delete
  19. the target directory. Since we're adding test, we want to make
  20. sure we're starting with a clean slate. So I'm going to
  21. delete it, and there it is. Looks like it's
  22. gone, won't stay gone for long, but it's gone for
  23. now. Okay. Now let's go to Eclipse. Going to refresh
  24. the project, since we've added the test directory. And deleted
  25. the target directory. Okay. So target on, target's still
  26. there. So whenever you do delete the target directory, it
  27. actually pretty much automatically gets recreated right away with a
  28. couple of things in it. But it doesn't have everything
  29. that's needed. Here down in the source directory,
  30. you'll see the test folder now, and it has
  31. two tests. It has in the domain
  32. package, and it has in the SPI packet.
  33. So let's take a look at the tests.
  34. First, I'm going to look at Here we have
  35. our class ProfileTest. So I'll start by defining
  36. some values that we're going to need in our tasks.
  37. And we do the setup, and all we're doing this set, for setup here is we create a
  38. new profile and we supply some values. Then we
  39. have to tear down method, which one we need. And
  40. then here's our first test. We're testing the Getters.
  41. Very simple. Just checking, that the values in the profile
  42. are in fact values we put in the profile.
  43. Then we check what happens when we update the profile.
  44. So what we're going to do, is update the display
  45. name and the t-shirt size. And then we want to
  46. check that the display name is updated, and the
  47. t-shirt size is updated. But in fact, the user ID
  48. and the email, don't get updated. They need to
  49. remain as they were. And then this other function here
  50. is commented out, because it tests some functionality that you
  51. haven't implemented yet, so the test wouldn't work. Now let's
  52. look at So here we are,
  53. ConferenceApiTest, and again, the first thing we do
  54. is set up some values for testing on. Have our service helper. Do the setup.
  55. And in this case, the main thing we're doing is creating a new user with
  56. an email, and a user ID. We have the tearDown method. And then we stop testing.
  57. So the first thing we do is testing getting the
  58. profile first time. Now we test saving the profile. Now we
  59. test saving the profile with null values and, so on. Have
  60. a look at the different tests that we do, and then
  61. you get to a point where it's commented out, and that's
  62. because they're testing functionality you
  63. haven't implemented. Like, you can't test
  64. creating a conference, because we haven't written function to create a
  65. conference here. And as you go through the lesson, you can
  66. come back into And comment the testing
  67. functions, as the functions are ready for testing.
  68. Okay. Now we're going to look at running
  69. the project when we've got tests. So if we
  70. go up to Conference Central, this time I'm
  71. going to choose Run As and then Run Configurations. And
  72. this is my configuration to run the, run
  73. the Dev Server on localhost. And you see here,
  74. there is Skip Tests check box. So by default, tests
  75. are not skipped. It hasn't mattered up until now, because we
  76. haven't had any tests in there. So it didn't matter
  77. whether they were skipped or not. But now, the tests will
  78. be run. If, if at any point you find that
  79. the tests are blocking you or you want to deploy without
  80. the test, you can come and click this Skip Tests, but
  81. let's not do that. Okay. So I'm going to run. Now
  82. I'm running as per normally see the tests? Okay. My Dev Server is
  83. running. Let me scroll back up and see what the results of the tests were. Okay.
  84. So it run seven tests. There were
  85. zero failures. Zero errors, zero skipped, and it
  86. took 0.415 seconds, and then here's the
  87. summary. Okay, good. Okay. We'll that's all fine.
  88. But what happens if you actually do have an error? So to test that, to
  89. test the tests. Let's introduce an error. So
  90. since we're testing the profile functionality, I'm going
  91. to make one of the functions to do
  92. with profiles return an unexpected result. Okay. So
  93. we have the getProfile method, and this gets
  94. the profile associated with the logged in user.
  95. And to get the profile entity out of the
  96. datastore, we have to first create a key. And
  97. we specify the class, which is profile.class. And then
  98. the see it's the key, user ID. But let's
  99. say we made a mistake, and we put the
  100. user ID inside a string. Which is something that
  101. does happen. Now, there's no error here. This is
  102. a valid kind of value here, so. It doesn't
  103. show me an error. Now lets' see what happens when we run our tests.
  104. Now I'm going to run the project, on localhost. Okay. This time we've
  105. got an, an error. Failed to execute, and we got an error in the test.
  106. And we got the error in testGetProfile. No huge surprise there.
  107. So, you see we have the stack trace. But at the bottom, we have a nice summary
  108. where it shows the tests, the gave in error, and how many failures. And now, the
  109. other thing I want to show you, it's over in your target directory.
  110. May need to refresh your project here. In the target directory, you
  111. see a folder called surefire-reports.
  112. And this directory contains results of the report.
  113. So if we look at ProfileTest.txt, this is not
  114. where we had our errors. Zero failures, zero errors.
  115. If we look at ConferenceApiTest.txt, whoo, lots of errors.
  116. But here, failures. There was, there's actually only one
  117. error, but this is stack trace. But now, if
  118. we come down, I want you to look at
  119. the, the, see what happens with the XML files.
  120. If I click on ConferenceApiTest.xml, it'll show me
  121. the functions that got called, and the ones
  122. with the error, or the failures. In this
  123. case here, it takes me straight to where
  124. I had the error. The problem I can see right here is that, is that the user ID
  125. did not match what was expected. So, I'm going to go ahead now actually and just
  126. fix my code before I forget. Okay. There's my code
  127. we'll fix. Now when I run it, I won't get
  128. any errors. As you continue through the lesson, be sure
  129. to add the test for the new functionality as you
  130. implement it. In some cases, you'll need to get the
  131. test file from the appropriate lesson folders. As you implement
  132. new endpoint functions, you can simply uncommon the tests that
  133. are already in Conference API Tests. And if you deviate from
  134. the code that we have you write, like if you add
  135. your own functions or you change what the functions do, then you're
  136. going to need to update the tests and add your own tests
  137. to make sure that you're testing the functionality that's in your application.