Lecture 10

0:44 there is a method called equals – every class has it.
if this is not defined explicitely and if you write something like:

r1.equals(r2)

This is to test whether the two references point to the same object.
Many classes define equals in order to compare the content of two objects. An example of such class:String class

2:20 the example that Mr Shevchuk show reveals how can the == operator be different than the equals function

4:26 degrees of equality … quite interesting
1. reference equality, the method (usually equals) does exaclt the same thing as == operator
2. shallow structural equality … objects could be different objects but their contents have reference quality (I remember about a quite interesting debate about the the difference between shallow and deep objects copy, but in C++ not in Java, that I had with a workmate) a really nice and subtle feature of object oriented languages, also one of the things that may distinguish between an amateur and a senior programmer
3. deep structural equality – this was a little bit anticipated by the previous aspect, what it means?

two objects have deep structural equality if their fields are equal according to the equals method

4. logical equality, same as mathematical equality

very illustrative the example that starts at 9:06

those all explanations about recursivity and algorithms are not so comprehensive for me and sometimes (actually more times) makes me have problems in understanding the concepts. I didn’t studied algorithms, neither data structures so far and it seems that Mr Shewchuk is using in all his Data structures lecture series some notions that he considers to be known apriori . I will really have to have a closer look on things like: quick sort, bubble sort, greedy algorithms (my apologies if those things are too trivial)

16:35 code testing

17:26

I really like CS 61B and I think most of the material in this course is interesting, but I have to confess that the rest of this lecture will be a dreadful bore

that was good! :))

so, here we are “testers all over the world unite yourself”
I am quite familiar with this topic, so let’s see if things are working how I knew

3 types of testing: modular (or better known, unit testing), integration testing (done after all pieces of code, which were “unit-tested” before, are bound together, you guys, testers, you know how many pains this can give you) and … result verification

Modular testing … what is this all about? I see that in this course the basic testing unit which is chosen to exemplify the testing mechanism, is the function, well … method (if we’re speaking about classes)

there are two ways to test the methods: test drives (methods which reside in the main method which are calling the code and check if the result makes sense) and stubs (which, in contrast with test drives, are not calling the tested code, but are called) Last ones, like the name is saying, are designed to replace a method which is not currently implemented, and simply returns some dummy data and serves to test the initial calling method. Another use of it, is to find whether the bug lies in the calling method or in the callee

Integration tests are a “fancy” word for the testing process that follows the integration of multiple pieces of code (methods, interfaces and many others…) into one single unified software architecture. This testing phase is quite nasty because hidden bugs, that were not discovered in the unit testing phase are harder to be discovered now.

The discussion steers towards degubbing, actually a notion very related to the one of testing, nowadays since we have IDEs and debuggers.

32:36 learn to use the Java debugger …

Result verification (honestly this is the first time when I hear about this, and it is quite a lot of time since I am in the testing world) – the idea is to define some invariant data, that you know the value, and after running the code you may check whether your code is changing those invariants. Another way to check if your code is working properly would be to define a “check algorithm” that ensures that the result of the program is the correct one.

37:40 Assertions … I remember those are not only in Java but also in some Hardware Description Languages like VHDL or Verilog (by the way, for those of you who would like to learn more about this king of things, Verilog, VHDL , you can find here a really really good bunch of information) where assertions have pretty much the same use as in Java, to debug if the Verilog-VHDL code is properly programming the HW.

The idea is simple, the code stops if the assert condition is not fullfield, in case some error message is defined for the corresponding assertion, this is printed.

Be careful with the assertions because those can be turned ON and OFF via a Java interpreter option, as you may have expected 🙂 :

to turn them ON

java -ea
to turn them OFF

java -da

the default one, is supposed to be with the assertions disabled

44:45 … a very good point brought into the discussion by some student: try and catch, but those will be handled separately, the idea is that those are also very useful things in debugging

45:37 Regression testing (or in other words — a way to thrill a tester) this always give headaches… because whenever something changed in the code, regression tests have to be rerun in order to make sure that those changes didn’t introduced new bugs