Notes on MITx: 6.005.1x Software Construction in Java (Week 2)

This week the course is covering another two very important topics: Testing and Specifications.

LECTURE 3: Testing

Testing is a very important part of creating functionally correct programs.

Testing will be always incomplete

You will try to test your program using three methods:

  1. Formal Reasoning, essentially you manually verify that your program works correctly
  2. Code Review: Another Programmer takes a look and says everything is ok.
  3. Test Suites: Essentially you write another program (which can have its own bugs) to test your program. You define the inputs and the expected output and compare them.

The course mentions again the residual defect rates of 1-10 defects/kloc(1000 lines of code). Again this does not cite where this number actually comes from. Especially when using Industry Standards and Test Suites this high number would drastically drop to an much lower number. However in the end it only would remain to be an assumption since the actual number cannot be determined.

You testing your program for every possible input (Exhaustive testing) is not feasible. The strategy to simply take a look and see if it works (Haphazard testing) will also not reveal all bugs. The same is true for “Random” testing. All of these test methods cannot be used to test software.

Write Tests

When you are writing tests you should think about how you can make your program fail. Test drive development takes the following approach.

  1. Specify what you want to program
  2. Write tests that would test the specification
  3. Write code so that your code passes the tests

The specification is key to define what inputs are possible and which outputs will be produced. (This also includes throwing errors)

Blackbox testing only focuses on the input and output of the function. These tests do not take into account how the algorithm actually works.

The alternative is Whitebox testing takes into account how the program is implemented.

Test Coverage

Now that you have written tests for all of your code, did you also test all of your code? Coverage takes a look at if all Statements and all possible paths through your code are covered.

There are various Code coverage tools available that you can run and then visually see which part of the code is covered by your tests.

In reality you should try to achieve a coverage of 70-90% of your code achieving 100% is usually not possible due to time constraints. Of course this is not the case if you are using Test Driven Development.

Running Tests

Usually you would create a Testsuite of Unit Tests. You should integrate these tests into your build process to ensure that the tests run automatically. Especially when you modify existing code this will ensure that your modifications will not accidentally break something unintentionally.

When working with multiple people you should add hooks to your git repository that it rejects code that does not pass your test suite.

 

LECTURE 4: Specifications

This lecture is going to cover preconditions and post-conditions in method specifications, and how to write correct specifications.

What is a specification?

The lecture defines a specification primarily only concerning how the interfaces are defined and how the specification document essentially is used as communication device to talk to the client.

Now this actually assumes that the client is another programmer that wants the module/system to do a specific functionality. In my work experience usually the client has no technical background and expects the programmer to know what he wants.  Yes the specification is the key document on how to negotiate which features etc. the client requires, it is however not exactly defined which functions or how interfaces should be created, this is usually the task of the programmer.

The course actually is more talking about a documentation document how and which interfaces exist in the code you are programming for the client. The documentation is key whenever other programmers need to use the code you have programmed.

In either case, the specification document is a key document. It defines the work that needs to be done. The document shields the programmer from the client, if the client forgot to specify something, thus the programmer did not implement it he can prove it was the clients fault. At the same time the programmer is bound to the document that he actually implements all features. (or negotiates, talks with the client that the functionality is unfeasible, or not possible to be implemented)

Pre and Post Conditions

For each function you require the preconditions (what inputs) and postconditions (what outputs).

The inputs may have to have a specific structure, cannot be a certain value etc. These need to be checked.

The function also will have various outputs. This is of course the result, and how the result should be structured, the method also can throw errors.

Write test cases

Essentially if the specification of the function is well defined it is very easy to write the test cases. You simply follow the specification write tests to get the expected correct results and willfully pass wrong arguments into the function.

The rest of the lecture covers how to throw Exceptions. Which to use when.

HOMEWORK

Again another batch of “Java Tutor” exercises. They were as exciting as the last batch…

However this time they also provided a “warm up” problem set. The warm up is just to implement the mathematical “quadratic roots formula”.

The straightforward implementation of the formula will not pass all the Unit Tests. You need to take a deeper look at Java to actually figure out why the last Unit Test fails, and how you can change your code to make your code pass the test.

Notes on MITx: 6.005.1x Software Construction in Java (Week 1)

MITx has released a course titled “Software Construction in Java”. The course is aimed for more experienced Developers and is going to teach a couple of general principles of Software Development.

The course has the goal that you develop good code, which is defined as:

  • Safe from bugs: Correct behavior of the code, now and in the future
  • Easy to understand: Code should be easily understandable by other developers
  • Ready for change: Architectural patterns that allow you to modify the code without major rewrites.

Over the next couple of weeks I will complete this course and will publish my notes and thoughts on the material.

You can also take the course at https://www.edx.org/course/software-construction-java-mitx-6-005-1x

Why am I taking this course?

I have worked with Java in the past. I do not prefer using the language. However in the Python course from MIT was fantastic and thought very interesting concepts that apply to all languages.

My hope is that this course will teach broader concepts and the language they are using just happens to be Java.

LEcture 1: OVerview + Static Typing

The first lecture i skipped most of the videos, they seemed more like an introduction to Javas static typing, which I was already familiar with.

Lecture 2: Code Review

The second lecture takes a look at good Coding Practices.

Code Review

Lecture notes:

The purpose of a code review has two main goals:

  • Improve the code
  • Improve the programmer

Personal notes:

In reality on many programming projects the “Code Review”- Phase is cut due to budget constraints, lack of time and personal feelings. Remember when you do a code review you may hurt the feeling of another programmer, who thinks he is infallible.

This usually causes that more and more bad code is written. Making the project not maintainable and unreliable.

If it is possible for your project to do Code Reviews, you defiantly should do them, and have a very specific action plan that the other developer can learn from his mistakes.

Style Standards

Lecture notes:

You can find good style guides at https://github.com/google/styleguide

Personal notes:

Every programmer has his personal style how he likes to format and read his code. All university classes (including this one) do not provide a style guide. With the consequence that also no style guide is enforced.

In larger projects this would not be possible. The version control systems suddenly cause problems, create merge conflicts etc.

Styleguides should never be manually enforced. That would be tedious and create a lot of unnecessary work. The guide should be enforced by your build process. This prevents programmers from using their own style guide, avoids merge issues, is easier to manage, and it is psychologically better for the programmer that the machine rejects code rather than another programmer.

The best practice would be that every code commit gets checked prior to be allowed into the repository. This ensures that every developer is playing by the same rules. (To find more information on this subject google for “git hooks” and “java checkstyle”)

Code Smells

  • Don’t Repeat Yourself (DRY)
  • Comments where needed
  • Fail fast
  • Avoid magic numbers
  • One purpose for each variable
  • Use good names
  • No global variables
  • Return results, don’t print them
  • Use whitespace for readability

Personal notes:

While the lecture presents various strategies to prevent the most common beginner mistakes. These are just a select few of all the various types of code smells.

I prefer to use the IDE IntelliJ, it has a feature called “Code Inspector”. It will scan your code and suggest fixes for a lot of types of code smells.

Good code should never have obvious code smells.

Homework

For the “Java Tutor” Homework assignments you must use an Eclipse Plugin.  So sadly you have to use Eclipse with a custom built plugin and as usual I have had a lot of fun with randomly crashing Eclipse, the plugin giving me over and over again the same questions.

The “Java Tutor” is overall quite weak. The questions are more like “fill in the blanks” and only accepts a single correct answer. Usually the titles of the links to the related materials give away the correct answer.

However if you enter the wrong value, you can simply click “Show Answer”, copy the solution and progress without penalty.

Java: Multiple Functions and one ErrorHandler

Y2K Bug by Cards Against Humanity from The Noun Project

Let’s say you have function fooA() and function fooB() both functions are very similar and throw similar errors.

 public static void fooA(){
         try{
             throw new FileNotFoundException();
         }
         catch (Exception e){
             exceptionHandler(e);
         }
     }

     public static void fooB(){
         try{
             throw new FileNotFoundException();
         }
         catch (Exception e){
             exceptionHandler(e);
         }
     }
 

If you have the possibility to avoid duplicating code you could write a single Error handler and pass the Error to the Error handling function. However you still want to be able to distinguish between different types of Exception and for logging purposes you should mention which function actually caused Exception. The easiest way to figure the Method name is to use e.getStackTrace()[0].getMethodName();
Alternatively you can pass the method name to the Errorhandlerfunction. To do that you can figure out the method name via:

 String methodName = Thread.currentThread().getStackTrace()[1].getMethodName();
 

To determine the various Exceptions there are two possibilities:

Method 1: Use instanceof

The downside to this method is that it is not as readable and identifiable as ErrorHandling function. (However this depends on personal preferences)

     public static void exceptionHandler(Exception e){
         if (e instanceof FileNotFoundException){
             System.out.println(e + " " + e.getStackTrace()[0].getMethodName());
         } else if (e instanceof Exception) {
             System.out.println(e.getStackTrace()[0].getMethodName());
         }
     }
 

Method 2: re-throw the Error

Well you are still throwing around with errors, but it is clearly identifiable as Error handler.

  public static void exceptionHandler(Exception e){
         try {
             throw e;
         }
         catch (FileNotFoundException e){
             System.out.println(e + " " + e.getStackTrace()[0].getMethodName());
         }
         catch(Exception e) {
             System.out.println(e.getStackTrace()[0].getMethodName());
         }
     }