1. Sadegh Aliakbary Sharif University of Technology Spring 2011

2. Agenda Software Quality Characteristic of a good software Test Unit Testing Refactoring Spring 2011Sharif University of Technology2

3. Quality of Product The producer should ensure about the quality of the products Quality Control Any business, any product Spring 2011Sharif University of Technology3

4. A Cook Spring 2011Sharif University of Technology4

5. Maintenance check of electronic equipment on a Navy aircraft. Spring 2011Sharif University of Technology5

6. A Car Maker Spring 2011Sharif University of Technology6

7. Quality Control Quality should be tested A product is not finalized, before the test Different kinds of test, check different kinds of quality Spring 2011Sharif University of Technology7

8. Software Quality We are programmers Programmers produce software What are characteristics of a good software? Many parameters. E.g. Conformance to requirements Performance Time Memory Maintainability Changeability Different kinds of test, check different kinds of quality Spring 2011Sharif University of Technology8

9. Test Target System Test Test the system as a whole For performance, correctness and conformance. Unit Test Test the units and modules Test of a component Test of a class Test of a method Spring 2011Sharif University of Technology9

10. How to Test Software Manual Test Try it! Test Tools Performance Test Profiling JProfiler, TPTP Load Test Jmeter Test Code Unit Tests Test Teams Spring 2011Sharif University of Technology10

11. Test Code Business Code The code, written for implementation of a requirement Test Code The code, written for test of an implementation Spring 2011Sharif University of Technology11

12. Unit Testing A process for the programmer Not a test team procedure For improving the code quality Reduces bugs Test of units of software before the software is completed Unit: method, class Spring 2011Sharif University of Technology12

13. Classical Unit Testing Writing main() method Some printlns Drawbacks? Spring 2011Sharif University of Technology13

14. Drawbacks Test code coupled with business code In the same class Written tests are discarded One test at a time The programmer executes the tests himself Test execution is not automatic The programmer should check the result of each test himself The test is passed or failed? The test result interpretation is not automatic Spring 2011Sharif University of Technology14

15. A Good Unit Test Code Repeatable Automatic Invocation Acceptance (Pass/Failure) JUnit helps you write such tests Spring 2011Sharif University of Technology15

16. JUnit, First Example Spring 2011Sharif University of Technology16

17. JUnit, The Green Bar Spring 2011Sharif University of Technology17

18. public class Testing { @Test public void testNormal() { int[] array = {3,2,1,4}; int[] sorted = {1,2,3,4}; Business.sort(array); for (int i = 0; i < sorted.length; i++) { Assert.assertEquals(sorted[i], array[i]); } @Test public void testEmptyArray() { int[] array = {}; try{ Business.sort(array); }catch(Exception e){ Assert.fail(); } Assert.assertNotNull(array); Assert.assertEquals(array.length, 0); } Spring 2011Sharif University of Technology18

19. Assertions assertNull(x) assertNotNull(x) assertTrue(boolean x) assertFalse(boolean x) assertEquals(x, y) Uses x.equals(y) assertSame(x, y) Uses x ==y assertNotSame fail() Spring 2011Sharif University of Technology19

20. Annotations @Test @Before @After @BeforeClass @AfterClass Spring 2011Sharif University of Technology20

21. Spring 2011Sharif University of Technology21

22. A Good Unit Test is Automated Through Repeatable Independence Professional Spring 2011Sharif University of Technology22

23. Test Driven Development Test First Development Before writing a code, write the tests! Spring 2011Sharif University of Technology23

24. TDD Spring 2011Sharif University of Technology24

26. Refactoring A disciplined way to restructure code In order to improve code quality Without changing its behavior a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. Spring 2011Sharif University of Technology26 Martin Fowler

27. Refactoring Refactoring is the process of changing a software system In such a way that it does not alter the external behavior of the code But improves its internal structure It is a disciplined way to clean up code It minimizes the chances of introducing bugs When you refactor, you are improving the design of the code after it has been written. Spring 2011Sharif University of Technology27 Martin Fowler

28. Refactoring By continuously improving the design of code, we make it easier and easier to work with Spring 2011Sharif University of Technology28 Joshua Kerievsky, Refactoring to Patterns

29. The Two Hats Kent Beck's metaphor of two hats Divide your time between two distinct activities adding function refactoring Spring 2011Sharif University of Technology29

30. Why Should I Refactor? Refactoring Improves the Design of Software Refactoring Makes Software Easier to Understand Refactoring Helps You Find Bugs Refactoring Helps You Program Faster Spring 2011Sharif University of Technology30

31. When Should You Refactor? The Rule of Three: Refactor When You Add Function Refactor When You Need to Fix a Bug Refactor As You Do a Code Review Spring 2011Sharif University of Technology31

32. Bad Smells If it stinks, change it! Kent Beck and Martin Fowler. Bad smells in code Bad smells are source of problems Remove bad smells How? By Refactoring Spring 2011Sharif University of Technology32

33. Bad Smells Duplicated Code Long Method Large Class Long Parameter List … Spring 2011Sharif University of Technology33

34. Refactoring Techniques Extract Method Move Method Variable Class Extract Class Rename Method Variable Class Pull Up Push Down Spring 2011Sharif University of Technology34

35. IDE Support Refactoring techniques are widely supported by IDEs Practice it in Eclipse Spring 2011Sharif University of Technology35

36. Reference Refactoring: improving the design of existing code, Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts (1999) Spring 2011Sharif University of Technology36

37. Spring 2011Sharif University of Technology37