Develop with ease

Topalov Alex 2017

Test Example

Ruby Warrior

Intro

Part 1. Algorithmic Complexity 

Flog

Reek

Flay

Code duplications

Churn

LOC/NOC

Cyclomatic complexity

Saikuro, RuboCop

RuboCop

Security

Bundler Audit, Brakeman. *nix security

Where to?

1. CodeClimate

2. MetricFu

How to?

1. SOLID

2. Patterns

3. Refactoring 

SRP

(Single responsibility principle)

SRP

(Single responsibility principle)

SRP

(Single responsibility principle)

OCP

(Open/Closed principle)

OCP

(Open/Closed principle)

LSP

(Liskov substitution principle)

LSP

(Liskov substitution principle)

LSP

(Liskov substitution principle)

ISP

(Interface segregation principle)

ISP

(Interface segregation principle)

ISP

(Interface segregation principle)

DIP

(Dependency invertion principle)

DIP

(Dependency invertion principle)

Part 2. Tests

Code/Test Coverage

Mutator

(ex Heckle)

How to?

1. F.I.R.S.T
2. Refactoring

F - Fast

• A developer should not hesitate to run the tests as they are slow.
• All of these including setup, the actual test and tear down should execute really fast (milliseconds) as you may have thousands of tests in your entire project.

I - Isolated/Independent

• Arrange.
• Act.
• Assert.
• Avoid doing asserts in the Arrange part, let it throw exceptions and your test will still fail.
• No order-of-run dependency. They should pass or fail the same way in suite or when run individually.
• Do not do any more actions after the assert statement(s), preferably single logical assert.

R - Repeatable

• A test method should NOT depend on any data in the environment/instance in which it is running or state.
• Deterministic results.
  No dependency on date/time or random functions output.
• Each test should setup or arrange it's own data.
  Use Data Helper classes/Factories/Fabricators that can setup this data for re-usability.

S - Self-Validating

• No manual inspection required to check whether the test has passed or failed.

T - Thorough and Timely

• Should cover every use case scenario and NOT just aim for 100% coverage.
• Should try to aim for Test Driven Development (TDD) so that code does not need re-factoring later.

Part 3. Non-algorithmic Complexity

Learning Curve

Business requirements

Business requirements

We need a sales report

Business requirements

We need a sales report...
Can we have a date range there

Business requirements

We need a sales report...
Can we have a date range there...
We also need COGS to be present

Business requirements

We need a sales report...
Can we have a date range there...
We also need COGS to be present...

Can we exclude fraud/non-verified customers

Business requirements

We need a sales report...
Can we have a date range there...
We also need COGS to be present...

Can we exclude fraud/non-verified customers...
Is there are a way to see sales from new and returning customers?

Business requirements

We need a sales report...
Can we have a date range there...
We also need COGS to be present...

Can we exclude fraud/non-verified customers...
Is there are a way to see sales from new and returning customers?

Can we also have sales for shipped orders?

Business requirements

We need a sales report...
Can we have a date range there...
We also need COGS to be present...

Can we exclude fraud/non-verified customers...
Is there are a way to see sales from new and returning customers?

Can we also have sales for shipped orders?

Further reading:

1. 99 Bottles. Good for LSP understanding. Sandi Metz.
2. Principles, Patterns, and Practices. Robert Martin(a. k. a. Uncle Bob)
3. Integration Tests are a Scam. Joe Rainsberger
4. Refactoring from Good to Great. Ben Orenstein
5. Refactoring(https://refactoring.guru/​). Martin Fowler