session roadmap

Software craftsmanship

Why we're here?

Initial thoughts

roadmap

growing object-oriented software

"Object-oriented design focuses more on the  communication between objects than
on the objects themselves"

"An object-oriented system is a web of collaborating objects"

A web of objects

Coupling and Cohesion

CRC Cards

CRC Cards

We try to think about objects in terms of roles, responsibilities and collaborators.

"An object is an implementation of one or more roles; a role is a set of related responsibilities; and a responsibility is an obligation to perform a task or know information. A collaboration is an interaction of objects or roles (or both)."

 Example: How would you model a restaurant?

solid principles

solid principles

Robert 'Uncle Bob' Martin introduced it in 1995

What is S.O.L.I.D.?

S.O.L.I.D. is a collection of best- practice, object-oriented design principles which can be applied to your design

What is useful for?

• loose-coupling 
• higher maintainability 
• intuitive location of interesting code
• high cohesion
• encapsulation
• focus in what to do not how to do it
  

solid principles

SRP: Single Responsibility Principle

solid principles

Single Responsibility Principle (SRP)

"An object should have only one reason to change or exist"

Each complex problem cannot easily be solved as a whole.

It is much easier to first divide the problem in smaller sub-
problems.

"Divide et imperat" (Divide and Conquer)

This principle applies to classes and methods.

solid principles

Open-Closed Principle (OCP)

 "We should write our modules assuming that they can and should be extended, without requiring them to be modified"

solid principles

Liskov Substitution Principle (LSP)

aka design by contract

In a nutshell:

"If you have a base class BASE and subclasses SUB1 and SUB2, the rest of your code should always refer to BASE

and NOT SUB1 and SUB2"

"Prefer composition over inheritance whenever possible... though"

solid principles

Interface Segregation Principle (ISP)

“many client-specific interfaces are better than one general purpose interface”

Think … to create specialised interfaces serving specific requirements, rather than finding the mother of all interfaces, that will service the universe.

"clients shouldn't be forced to implement interfaces they don't use or even care"

solid principles

Interface Segregation Principle (ISP)

solid principles

Interface Segregation Principle (ISP)

solid principles

Dependency Inversion Principle (DIP)

“depend on abstractions (interfaces), not on corrections (implementations)”

solid principles

Conclusions and Benefits

solid principles

Conclusions and Benefits

Other SD principles

OTHER SD PRINCIPLES

CLEAN CODE

"Beauty of style and harmony and grace and good rhythm depends on simplicity" Plato  The Republic

“Always leave the camp ground cleaner than you found it.”  the boy scouts rule

Clean Code 

 int d; // elapsed time in days

int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

 class DtaRcrd102 {
private Date genymdhms;
private Date modymdhms;
private final String pszqint = "102";
/* ... */
};

 class Customer {
private Date generationTime;
private Date modificationTime;
private final String recordId = "102";
/* ... */
};

CLEAN CODE 

 Date newDate = date.add(5);

 //addDaysTo or increaseByDays

 if (timer.hasExpired() && !timer.isRecurrent())

if (shouldBeDeleted(timer))  //preferred

 if (!buffer.shouldNotCompact())

 if (buffer.shouldCompact()) //preferred

CLEAN CODE

 public void pay() {
   for (Employee e : employees) {
      if (e.isPayday()) {
        Money pay = e.calculatePay();
        e.deliverPay(pay);
      }
   }
 }

//preferred
 public void pay() {
    for (Employee e : employees)
       payIfNecessary(e);
    }
 
 private void payIfNecessary(Employee e) {
    if (e.isPayday())
       calculateAndDeliverPay(e);
    }

 private void calculateAndDeliverPay(Employee e) {
    Money pay = e.calculatePay();
    e.deliverPay(pay);
 }

CLEAN CODE

 if(level + 1 < tags.length)
 {
   parts = new Parse(body, tags, level + 1, offset + endTag);
   body = null;
 }

  int nextLevel = level + 1;
 if(nextLevel < tags.length)
 {
   int delay = offset + endTag;
   parts = new Parse(body, tags, nextLevel, delay);
   body = null;
 }

clean code

public class AnyClass
{
  public static final String DEFAULT_PATH = ".";
  public static final String DEFAULT_ROOT = "FitNesseRoot";
  public static final int DEFAULT_PORT = 80;
  public static final int DEFAULT_VERSION_DAYS = 14;
  ...
}

CLEAN CODE - Comments

CLEAN CODE - Formatting

CLEAN CODE - Defensive Programming (JSR305)

@Nonnull
@Nullable

CLEAN CODE - Automate Your

Coding Standard 

Clean code - takeaways

refactoring

"Refactoring is the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improves its internal structure"

"refactoring is to code what the gym is to a body builder == necessary" anonymous

REFACTORING

When Should You Refactor?

When shouldn't you refactor?

REFACTORING

REFACTORING

REFACTORING

Bad Smells in Code

Train wreck

 SelectionUtils.processDisplayOdds(eachEvent.getContent().getFirstBook().getContent()
                            .getSelections());

 if (selectionDisplayOptions.getMarketTypeIdsForSelectionOrderingByName().contains(event.getContent().getFirstBook().getContent().getMarketTypeId())) {SelectionUtils.sortSelections(event.getContent().getFirstBook().getContent().getSelections(), SelectionSortType.BY_NAME);}

if (selectionDisplayOptions.containsCouponMarketTypeId(event.getCouponMarketTypeId())) {SelectionUtils.sortSelections(event.getCouponSelections(), SelectionSortType.BY_NAME);}

REFACTORING

Bad Smells in Code

Train wreck

Code in the language of your domain

and make your code more readable

tip: A train wreck access is telling you to add a method to your interface

It's much easier to test as it just needs one stubbing

... And please don't break the encapsulation of your object

REFACTORING

 BetSlipUtils.addSelectionToBetSlip(quickbetSlip, user, site, betSlipServices, sbBusinessLogic, betSelectionMap.get("selectionId"), betSelectionMap.get("marketId"),
                betSelectionMap.get("eventId"), betSelectionMap.get("priceUp"), betSelectionMap.get("priceDown"), betSelectionMap.get("americanOdds"), betSelectionMap.get("decimalOdds"), betSelectionMap.get("handicap"), betSelectionMap.get("handicapId"), betSelectionMap.get("eachWayPlaceTerm"), betSelectionMap.get("eachWayReduction"));

REFACTORING

REFACTORING

TESTING the web of objects

testing software

types of tests

What is the testing big picture?

Acceptance

Integration

Unit

types of tests

• Acceptance: Does the whole system work?
• Open discussion in testing world over the terminology
• end-to-end
  
• functional tests
• system tests
• We use “acceptance tests” to help us, with the domain experts, understand and agree on what we are going to build next.
• We also use them to make sure that we haven’t broken any existing features as we continue developing.
• Acceptance tests are a superset of all other tests.
• They are expensive, require a significant amount of time to execute themselves (nightly builds).

types of tests

types of tests

Unit test: Do our object do the right thing?

Verification vs design

Different testing approaches with two opposites beliefs

Verification vs design

Verification VS design

The terms designer and verifier have been introduced to show boundaries between testing approaches.

What kind of developer are you?

There is not such a 100% designer or 100% verifier thing, we all fall somewhere in between.

Behaviour driven development

• Programmers wanted to know where to start
• What to test and what not to test
• How much to test in one go 
• What to call their tests
• How to understand why a test fails?

BEHAVIOUR DRIVEN DEVELOPMENT

“a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology.” Dan North 

BEHAVIOUR DRIVEN DEVELOPMENT

Testing and code coverage

100% code coverage isn't the goal

100% sounds awesome but...

does not guarantee the lack of defects—it only guarantees that all of your code was executed

is this what we want?

So rather than obsessing about code coverage, focus your attention on making sure that the tests you do write are meaningful and test the functionality

unit testing

• How to approach unit testing?
  
• state vs interaction
• Tools
  
• JUnit
• Mockito
• PowerMock
• Matchers (assertJ)

unit testing

How to approach unit testing?

This is when we start to think about

UNIT TESTing

• Conventions that could be followed or agreed:
  
• Follow BDD approach and describe specifications not a test case 
• We are not testing methods we are testing functionality, is this clear?
• Test method names should be sentences
  
• A simple sentence template keeps test methods focused
  

ClientDetailsValidatorUnitTest

itShouldFailForMissingSurname

testShouldFailForMissingTitle

UNIT TESTING

HOW TO APPROACH UNIT TESTING?

unit test

state vs interaction

UNIT TEST

@Test(expected = LoginException.class)
public void shouldThrowErrorExceptionWhenInvalidUser() throws LoginException {    sut.login("error", "password");
    fail("it shouldn't reach here");}

UNIT TEST

• state verification
  
• What do we use @Before for?
• is executed before every test.
• should include state shared by all tests
• if we have specific initial state for a test should be removed from @Before and moved inside the test as a test fixture

 @Before
    public void setUp() {
        ukashDepositForm = createDummyUKashDepositForm();
        serviceCallResult = new ServiceCallResult();
    }

@Test
public void shouldReturnExpectedAllowedMethods() {
// test fixtures
List<DepositMethod> aListOfValidDepositsMethods = listOfValidDepositsMethods();
List<DepositMethods> aListOfAllowedMethods = aListOfAllowedMethods();

UNIT TEST

• behaviour verification
  
• we test (verify) how our sut interacts or behaves with other collaborators (dependencies(mocks))
• there is a general misunderstanding when referring to a mock
• a dummy object needs to exists, no collaboration needed
• we use test doubles to act as a collaborators
• Mockito allows us to stub methods a.k.a stub
• an object becomes a mock when is used to verify the interaction with the sut

UNIT TEST

• behaviour verification
  
• verify: Verifies certain behaviour happened X times

  public static <T> T verify(T mock) {
        return MOCKITO_CORE.verify(mock, times(1));
    }

verify(mockUser).getAccountId();verify(mockUser, times(0)).getCurrencyId();
verify(model).put(eq("ukash"), eq(TRUE));

UNIT TEST

 @RunWith(MockitoJUnitRunner.class)

 @InjectMocks
 DepositBusinessLogicImpl sut = new DepositBusinessLogicImpl();

 @Mock
 ModelMap model

UNIT TEST

 when(site.getTimeZone()).thenReturn(A_VALID_UK_TIMEZONE);

 given(site.getTimeZone()).willReturn(A_VALID_UK_TIMEZONE);c`sdv

when(mock.getTransaction(anyLong(),any(TransactionSearchType.class)).thenReturn(txList);

• verification of params used for method invocation

  verify(model).put(eq("ukashDepositCurrencyId"), anyDouble());

• Throwing exceptions

 doThrow(new Exception()).when(mock).method(any(UkashDepositData.class));

UNIT TEST

Tools

Mockito and BDDMockito good practices

• Don’t mix with Spring Integration Test
• Don’t mock your model (dummies?)
  
• Don’t abuse mocks.. code smell?
  
• Don’t replace asserts with verify
  
• stubbing section shouldn't be used as a replacement for verify section

UNIT TEST

 @RunWith(PowerMockRunner.class)

 @PrepareForTest(SBLoginSecurityServiceImpl.class)

whenNew(SecurityContextLogoutHandler.class).withNoArguments().thenReturn(securityContextLogoutHandler);

UNIT TEST

• Fluent assertions for java:
  
• assertJ is a Java library that provides a fluent interface for writing assertions
  

assertTrue(yoda is instanceof Jedi.class);assertEquals(foundJedi, yoda);assertNotEquals(foundSith, yoda);

 assertThat(yoda).isInstanceOf(Jedi.class)
                .isEqualTo(foundJedi)
                .isNotEqualTo(foundSith);

 assertThat(newHires).containsOnly("Gandalf", "Arwen", "Gimli");

 assertThat(outcome).includes(
                   entry("stakeMultiplier", new Double(1.0)),
                   entry("taxType", TOTALSTAKE),
                   entry("numberOfBets", 1L),
                   entry("betType", SINGLE),
                   entry("taxRate", 5.0));

conclusions

References

future topics

1. TDD
2. Custom Matchers and Argument Captor
3. Spring Servlet API mock package
4. Power Mock advanced
5. Mockito Answers