Centric - UAIC

(1)

DEPENDENCY INJECTION

May 29, 2018 FLORIN OLARIU

(2)

ABOUT ME

•

22+ years experience in software development(mainly as Technical Lead/Architect)

•

Started in Centric 6 years ago

•

Current role: .NET Discipline Coordinator/Domain Architect in Centric

•

Professor Collaborator - Alexandru Ioan Cuza University – Computer Scince Faculty

• PhD -> Increasing security for online payments by using biometrical algorithms

• Introduction to .NET/Software engineering

TITLE PRESENTATION May 29, 2018

(3)

AGENDA

•

7 Deadly Developer Sins

•

Dependency Injection Pattern Overview

• Demo : .NET Core Sample

• Demo : Java Spring Sample

• Demo : Angular Sample

•

Unit testing

• Short Story

• Sandro Mancuso -> About unit testing story

• Why Unit Testing?

• What Is A Unit Test?

• Unit Test Example

• Unit Test Pyramid

• Tips For Writing Great Unit Tests

• Testing Goals

• Demo : .NET Core sample

•

Suggestions/Materials

•

Summary

•

^Questions

May 29, 2018 TITLE PRESENTATION

(4)

7 DEADLY DEVELOPER SINS

(5)

7 DEADLY DEVELOPER SINS

1.

Potential bugs

(6)

7 DEADLY DEVELOPER SINS

1.

Potential bugs

2.

Coding standard breach (or lack of)

(7)

7 DEADLY DEVELOPER SINS

1.

Potential bugs

2.

3.

Duplications

(8)

7 DEADLY DEVELOPER SINS

1.

Potential bugs

2.

3.

Duplications

4.

Lack of unit tests

(9)

7 DEADLY DEVELOPER SINS

1.

Potential bugs

2.

3.

Duplications

4.

Lack of unit tests

5.

Bad distribution of complexity

(10)

7 DEADLY DEVELOPER SINS

1.

Potential bugs

2.

3.

Duplications

4.

Lack of unit tests

5.

6.

Spaghetti design

(11)

7 DEADLY DEVELOPER SINS

1.

Potential bugs

2.

3.

Duplications

4.

Lack of unit tests

5.

6.

Spaghetti design

7.

Not enough or too many comments

(12)

DEPENDENCY INJECTION PATTERN OVERVIEW

(13)

DEPENDENCY INJECTION PATTERN OVERVIEW

“Dependency injection (DI) is a technique for achieving loose coupling between objects and their collaborators, or

dependencies. Rather than directly instantiating collaborators, or using static references, the objects a class needs in order to

perform its actions are provided to the class in some fashion.

Most often, classes will declare their dependencies via their constructor, allowing them to follow the Explicit Dependencies Principle. This approach is known as "constructor injection". “ Source - https://docs.microsoft.com/en-

us/aspnet/core/fundamentals/dependency- injection?view=aspnetcore-2.0

(14)

DEPENDENCY INJECTION PATTERN OVERVIEW

“Every Java-based application has a few objects that work together to present what the end-user sees as a working application. When writing a complex Java application,

application classes should be as independent as possible of other Java classes to increase the possibility to reuse these classes and to test them independently of other classes while unit testing. Dependency Injection (or sometime called wiring) helps in gluing these classes together and at the same time keeping them independent.”

Source -

https://www.tutorialspoint.com/spring/spring_dependency_injecti on.htm

(15)

DEPENDENCY INJECTION PATTERN OVERVIEW

“Dependency injection is an important application design pattern. It's used so widely that almost everyone just calls it DI.

Angular has its own dependency injection framework, and you really can't build an Angular application without it.

This page covers what DI is and why it's useful”

“Dependency Injection (DI) is a way to create objects

that depend upon other objects. A Dependency Injection system supplies the dependent objects (called the dependencies) when it creates an instance of an object.”

Source - https://angular.io/guide/dependency-injection

(16)

DEPENDENCY INJECTION PATTERN OVERVIEW

“In software engineering, dependency injection is a technique whereby one object (or static method) supplies the dependencies of another object. A dependency is an object that can be used (a service)”

Source - https://en.wikipedia.org/wiki/Dependency_injection

(17)

DI - .NET CORE SAMPLE

(18)

DI - JAVA SAMPLE

(19)

DI – ANGULAR SAMPLE

•

https://stackblitz.com/angular/poxbnrrxyre?file=src%2Fapp%2 Fuser.service.ts

(20)

SHORT STORY

(21)

SHORT STORY

•

Cameron Purdy, Programmed in assembly, C, C++, Java, C#, etc.

– Answered Jun 12, 2014 · Upvoted by Jeff Nelson, Invented Chromebook, #Xoogler

(22)

SHORT STORY

•

“It's simple: Writing unit tests sucks. I personally (and absolutely) hate writing unit tests for code that I have

written. I would rather go to the dentist than write unit tests.

Maybe even the proctologist.”

(23)

SHORT STORY

•

“On the other hand:”

– “Even though I only started writing unit tests a few years ago, now I always write unit tests for software components that I am building.”

(24)

SHORT STORY

•

– “Even though I only started writing unit tests a few years ago, now I always write unit tests for software components that I am building.

– I have never regretted the time spent writing unit tests. Having unit tests is hugely valuable. Not just for finding bugs in the software, but for insulating against later breaking changes as well!”

(25)

SHORT STORY

•

– I have never regretted the time spent writing unit tests. Having unit tests is hugely valuable. Not just for finding bugs in the software, but for insulating against later breaking changes as well!

– I love finding a few bugs while writing unit tests. Why "a few"? Well, if I never found any bugs in my code with unit tests, I would consider them a waste of time. If I found too many bugs in my code with unit tests, I would be forced to consider a change of careers.”

(26)

SHORT STORY

• “On the other hand:”

– I have never regretted the time spent writing unit tests. Having unit tests is hugely valuable.

Not just for finding bugs in the software, but for insulating against later breaking changes as well!

– I love finding a few bugs while writing unit tests. Why "a few"? Well, if I never found any bugs in my code with unit tests, I would consider them a waste of time. If I found too many bugs in my code with unit tests, I would be forced to consider a change of careers.

– When a developer chooses to not write unit tests, they are telling their team-mates and those who depend on their software that this one developer's time is far more valuable than anyone else's time. Why? Because unit tests are an efficient investment, so not writing them means that other people's time is far,far less valuable than one's own time.”

(27)

SHORT STORY

• “On the other hand:”

– I have never regretted the time spent writing unit tests. Having unit tests is hugely valuable.

Not just for finding bugs in the software, but for insulating against later breaking changes as well!

– I love finding a few bugs while writing unit tests. Why "a few"? Well, if I never found any bugs in my code with unit tests, I would consider them a waste of time. If I found too many bugs in my code with unit tests, I would be forced to consider a change of careers.

– When a developer chooses to not write unit tests, they are telling their team-mates and those who depend on their software that this one developer's time is far more valuable than anyone else's time. Why? Because unit tests are an efficient investment, so not writing them means that other people's time is far,far less valuable than one's own time.

• All that said, I still hate writing unit tests.”

(28)

SANDRO MANCUSO -> ABOUT UNIT TESTING

STORY

(29)

SANDRO MANCUSO -> ABOUT UNIT TESTING STORY

“At that point I could not keep quiet anymore.

“Now that you know what the problem is, why don’t you write some unit tests around it?”

I really wanted to ask why he didn’t write the tests before his changes in the first place but I thought he probably wouldn’t take that well.

“What I’m doing is important and needs to be done quickly,” he said.

“I don’t have time to write tests.”

Then he deployed the new version of the application into the testing

environment again (note that no one else could use the testing environment while he was doing his tests), played an XML message into the inbound queue, and started looking at the logs again. That went on for another two days until the problem was actually fixed.”

– Mancuso, Sandro. The Software Craftsman: Professionalism, Pragmatism, Pride (Robert C. Martin Series) (p. 82). Pearson Education. Kindle Edition.

(30)

WHY UNIT TESTING?

(31)

WHY UNIT TESTING?

(32)

WHY UNIT TESTING?

(33)

WHY UNIT TESTING?

•

^Benefits

(34)

WHY UNIT TESTING?

•

^Benefits

• Find defects early

(35)

WHY UNIT TESTING?

•

^Benefits

• Prevent regressions

(36)

WHY UNIT TESTING?

•

^Benefits

• Provide living documentation (source code)

(37)

WHY UNIT TESTING?

•

^Benefits

• Provide living documentation (source code)

• Automate testing efforts

(38)

WHAT IS A UNIT TEST?

(39)

WHAT IS A UNIT TEST?

•

Definition 1

(40)

WHAT IS A UNIT TEST?

•

Definition 1

•

“A unit test is a piece of code (usually a method) that invoke another piece of code and checks the correctness of some assumptions afterwards.”

– Art of Unit testing

(41)

WHAT IS A UNIT TEST?

•

Definition 2

(42)

WHAT IS A UNIT TEST?

•

Definition 2

(43)

WHAT IS A UNIT TEST?

•

Definition 2

•

Essentially, a unit test is a method that instantiates a small portion of our application and verifies its behavior

independently from other parts.

(44)

UNIT TEST EXAMPLE

(45)

UNIT TEST EXAMPLE

(46)

UNIT TESTING PYRAMID

(47)

UNIT TESTING PYRAMID

(48)

TIPS FOR WRITING GREAT UNIT TESTS

(49)

TIPS FOR WRITING GREAT UNIT TESTS

•

Make each test independent to all the others

(50)

TIPS FOR WRITING GREAT UNIT TESTS

•

Any given behavior should be specified in one and only one test

(51)

TIPS FOR WRITING GREAT UNIT TESTS

•

Any given behavior should be specified in one and only one

•

testMock out all external services and state

(52)

TIPS FOR WRITING GREAT UNIT TESTS

•

Any given behavior should be specified in one and only one

•

testMock out all external services and state

•

“Any unit tests are better than none”

(53)

TESTING GOALS

(54)

TESTING GOALS

Goal Strongest technique

(55)

TESTING GOALS

Finding bugs (things that don’t work as you want them to)

(56)

TESTING GOALS

Manual testing (sometimes also automated integration tests)

(57)

TESTING GOALS

Detecting regressions (things that used to work but have unexpectedly stopped working)

(58)

TESTING GOALS

Automated integration tests (sometimes also manual testing, though time-consuming)

(59)

TESTING GOALS

Automated integration tests (sometimes also manual testing, though time-consuming) Designing software components robustly

(60)

TESTING GOALS

Automated integration tests (sometimes also manual testing, though time-consuming) Designing software components robustly Unit testing (within the TDD process)

(61)