Unit Testing and Refactoring

Unit testing is the discipline of writing code that tests other code.

• It is concerned with  most atomic behavioral units of  a system
• In procedural code, The units are often functions
• In OOs ,The units are classes.
• Testing in isolation is an important part of a unit tests

Problems with Large Tests :

• Error localization is difficult
• Longer execution time( that takes more than 1/10^th of a second to run )
• Coverage

Qualities of good unit tests :

• They run fast
• They help us localize problem
• Not talking to database
• Does not communicates across a network
•  Does not  touches the file system
•  Does not need to do special things to your environments( such as editing configuration files ) to run it

The Legacy Code Change Algorithm :

•  Identify change points  : The places where you need to make your changes depend sensitively on your architecture
• Find test points
• Break dependencies
• Write tests
• Make changes and refactor

Arrange, Act, Assert Pattern :

Every unit test is composed of three distinct parts:

•         The arrangement of the preconditions of the test
•         The performance of the act that is being tested
•         The assertion that the expected behavior occurred

Test-driven development : it is preferential not to have a working system under test before you write the unit tests.

Red, green, refactor Pattern :

• Write a failing test that targets the expected behavior of the SUT.
• Implement just enough of the SUT so that the new test passes without breaking existing successful tests.
• If any refactoring can be done on the SUT to improve its design or overall quality, now is the   time to do so.

Testing with Fakes :In TDD ,Actual implementations may not be available initially, We can fake implementations and use them in unit testing and fakes does not depend on any other third party libraries

Testing with Mock :Moq is the popular option for mocking implementations.

Test over-specification : The test  is over specified when It has knowledge of the SUT’s implementation rather than its expected behavior.

Avoiding test over-specification :

• The first option is to test behavior only. State-based tests are the best example of testing expected behavior. If a method accepts data as  input and returns altered data as output, the method can be treated as a black box for testing purposes. If the method accepts  inputs A, B, and C and returns outputs X, Y, and Z, it is irrelevant to the test how it arrived at such answers. The method can then be refactored without breaking the unit tests.
•  The second option is less attractive but is sometimes the only option. You can treat the unit test and the implementation that  it tests as one atomic unit: if one changes, so must the other .This is akin to accepting that the unit test is over-specified and  planning to throw away the unit test along with the production implementation if a refactor is ever required. This isn’t quite as wasteful as it might seem.

Writing tests for defect fixes : Write a failing unit test that captures two things: the exact reproduction steps required to force the defect to occur, and the expected behavior that is not currently enforced

Refactoring is the process of improving the design of existing code—after it has already been written .Each refactor differs in size and scope. A refactor could be a small tweak to a variable name to aid clarity, or it could be a more sweeping architectural change such as splitting user interface logic from domain logic when the two have become inappropriately intimate.

        Refactoring can be achieved in many ways like constants ,polymorphism, factory method, factory class  ..etc.