YouTube

Got a YouTube account?

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

English subtitles

← 05-34 Strong Oracles

05-34 Strong Oracles

Get Embed Code
1 Language

Showing Revision 2 created 07/16/2014 by Udacity Robot.

  1. Strong oracles are extremely useful and you should always use one if you can possibly find one.
  2. We're going to have a bunch of examples here.
  3. Let's start off with one of the important ones which is having an alternate implementation
  4. of the same specification, and if you think about it, this is what my random tester
  5. for the bounded queue did and perhaps what yours also did, and what I mean by that is
  6. my queue tester included a second implementation of the same queue abstraction.
  7. This one was implemented with a Python list and this was the second
  8. implementation of the same abstraction.
  9. We could use to actually check that the queue that we're testing gave the right answers.
  10. That's a very strong kind of a check.
  11. Another example that we use in my compiler testing work--
  12. we do what's called differential testing of compilers, and what that basically means is that if we have multiple
  13. implementations of the same compiler specification--that is to say, for example, multiple C compilers--
  14. we expect them to behave the same given equivalent inputs.
  15. Another way that we might get an alternative implementation is simply looking of an older
  16. version of the software that we're testing.
  17. This is checking not necessarily whether the software is correct but just whether we've broken it.
  18. And so remember for example that I said that in S.U.T probably could have tested
  19. the Pentium floating-point unit against the 487 floating-point unit.
  20. Another kind of old version oracle that tends to be extremely effective is after a refactoring change--
  21. that is to say, the change of our source code base that isn't intended to have any functional effect--
  22. we could use the version before and after refactoring.
  23. We can do differential testing of the version before and after refactoring and in that way
  24. try to get a pretty good idea that the refactoring did not actually break the code.
  25. The best kind of alternate implementations you could have is a reference implementation.
  26. That is to say, some sort of implementation of the specification, which you are after that you can trust.
  27. For example, following to implement an extremely high performance Python compiler,
  28. what I would do is I would use the regular C Python implementation
  29. as the reference implementation, and that would be treated as correct.