Gregory M. Kapfhammer

Associate Professor of Computer Science

http://www.cs.allegheny.edu/~gkapfham/

  
View  Edit  Uploads  History  Top  Changes  Search

Chapter 10: A Quick Overview




  1. Kent Beck asserts that the right design for a software system at any given time will have certain properties. What are these properties? How would you actually go about verifying that an application did indeed meet these properties?

  2. Beck writes "you don't have to write a test for every single method you write, only production methods that could possibly break." What are some of the characterisitcs of a method that "could possibly break"?

  3. Suppose that you were responsible for ensuring that we could use the principle of continuous integration during the long-term project? What types of tools or technologies would be needed to support the principle of continuous integration?


Answers:

  1. Kent Beck assert that must have certain properties in order to have a proper design. He simplifies these into four separate properties. The design must meet these properties 1) Runs all tests. , 2) Has no duplicated logic (such as duplicated property hierarchies). , 3) States every intention important to the programmers. , 4) Has the fewest possible classes and methods. These four properties must hold in order for the design justify its existence. In order to verify these properties actually hold for an application, first you must make sure it runs for all tests for all the possible inputs and outputs. If an application passes all these tests then you can begin to ‘cut the fat’ so to say. Try to simplify what is written in the code like if an operation must run for multiple cases only have one line of code for it instead of one for each case. You can do the same thing for classes and methods. If there are two or more methods or classes that could be combined with the same amount of code or less then combine then. Make sure though that when you are simplifying your program that you do not change what you want the program to do. If you can simplify the program no more with out affecting its functionality, then you have met these properties.

  2. Beck’s idea of testing only production methods is a good idea. Most methods may not even go beyond just passing its parameters to another method. It’s the methods that can change the outcome of our application that matter. Beck states it as if the application “could possibly break” meaning essential there is a possibility that something we don’t want to happen can. This could be a whole range of side effects or errors. Ever though a program may have worked for initial testing, that was for expected input. Say a user enters a number instead of a name. This could either fail or, even worse, go through the application and affect the rest of the data in negative ways. Also if certain variables are not reinitialized each time a method is called this could significantly affect the application’s performance.

  3. If we were to use the principles of continuous integration for the long-term project there would be certain tools and technologies that we would need. First and foremost we would need a machine dedicated to the integration of people’s code. That way once people are done writing their code that pasts all of it tests they can integrate it into the system and then test it with the rest of the system which has already been integrated. If they do not get their tests to work 100% with the rest of the system, they should dispose of what the wrote and start over. This way it ensures that the code integrated up to that point works properly. This practice would be more of a ‘tool’ and there are other similar ‘tools’ which would help to support continuous integration. Since continuos integration is the basis for Extreme Programming you should include the other aspects which make XP work. Communication is the most important of these. All communication is most effective if done face-to-face this way it ensures that all conflicts between ideas are settle quickly and effectively. This communication is made more efficient by having coding standards and thorough planning. This ensures that everyone is on the same page and realizes the ideas of not only what they are working on, but on how the whole program works. The final most important idea in order to make continuous integration work is refactoring. Refactoring is taking a piece of code that passes all its tests and thinking of how it can be simplified without losing its functionality. Using refactoring makes it easier for other programmers to integrate their code after you. If the code makes it simple to understand and add features it makes it easier to integrate. There are other principles like pair programming and an on-site customer that would make integration more effective as well.

~Brian McAlister

What happens at this integration machine? What does the term integration really mean? Is the integration really continuous if you sit down at the integration machine once per week and check to make sure that the code compiles and passes all of its test cases? Greg


  1. The first property od the right design for software at any given time is that one should (1) "run all the tests", (2) "Has no duplicated logic. Be wary of hidden duplication like parallel class hierarchies", (3)States every intentino important to the programmers" and last (4) Has fewest possible classes and methods." According to the text and Edward Trufte, one should take out everything that is not needed exclusively without changing the design and or outcome of the program. This takes care of the 3 tests and the 4th falls right into place with this process.

  2. Methods that could possible break are methods that have goto's, long nested functions, or calls and or other parameter passing that can be easily messed up. The testing is a good idea and maybe you should find where a method could break since that is probably what the user of the program would do. It seems that anytime you miss or overlook a place where a method could break, someone who knows nothing about the program finds the flaw.

  3. Some tools and techniques that would be needed to support the principle of continuous integration are to make sure that when running the tests, they pass with flying colors. With a machine dedicated to integration, developers can do all the steps of writing the code, testing and making sure that the code works all at one machine. I would guess, but am not exactly positive that JUnit is a good continuous integration tool. Actually I would think that the JUnit tool would be part of the continuous intergration process and other tools like compilers and things would also be parts of the process.

Chris Howell

How would you ensure that your test cases actually traversed all of the "code that could break"? Would you simply state that whenever you saw a code segment that "could break" you would immediately try to eliminate it? Again, what really happens on this integration machine? Greg

1. Brian and Chris pretty much summed it up. I'm not sure I can add much without repeating what they already said. And that wouldn't be good design (laugh laugh). I would however restress the point of making sure that the intention of the programmer is kept intact while trying to meet the other requirements. This seems potentally problematic.

2. In addition to Chris's and Brian's answers I would add that I'm not so sure I agree with the author 100 percent. How do we define "methods that can break?" Even the simplest methods are subject to human error, and therefore it is arguable that no method is too insignificant to test. However, there are cases, where testing one method will 'force' other methods that it calls to be correct in order for the test to pass. In this case, writing tests for the smaller methods called upon by the original method may be 'double testing' and a waste of time.

I think that this goes back to one of the comments that I recently made in class: you test "a lot" (potentially, everything that can break and then some) until you start to feel comfortable with the system. At this point, you back off on testing "a little bit" until you become more confident about your testing abilities. Some of these issues are addressed in greater detail in the JUnit FAQ. Greg

3. I agree with Brian and Chris that a single machine is dedicated for the purpose of integration. JUnit is a must. (Or perhaps another unit testing tool, but I assume the software has and will be coded in Java, so JUnit fits nicely.) Another tool not mentioned, but potentially necessary is a code repository, such as CVS. We need a way to track the many changes in the code and keep track of versions, especially should certain code break the system, or multiple updates made simultaneously.

Richard Geary

Aha! Very good response. If we have this integration machine, we certainly need to have some central repository that contains all of our source code. Then, we would log into the integration machine, delete the central repository, checkout a fresh repository, and then see if the code compiles and passes all of the test cases. Greg


Link to this Page