Test Driven Development with mORMot 2 with Delphi and FPC

Test Driven Development
with mORMot 2
The more tests…
the better

Welcome
Arnaud Bouchez
• Open Source Founder
• mORMot 1, mORMot 2, SynPDF, dmustache
• Modern Object Pascal
Delphi and FPC - Embarcadero MVP
• Synopse Tranquil IT
https://synopse.info https://tranquil.it

Test Driven Design
(aka TDD)
with mORMot 2

Disclaimer
This was a last time session…
so please by nice with me 

Today’s Special
• Technical Debt
• Software Seams
• Test Driven Design
• mormot2tests

Technical Debt
We all know or even still maintain
Delphi software older than a few decades
– Stuck with Delphi 7 / 2007
– Stuck with a single database
– Stuck with unmaintained UI component(s)
– Stuck with millions of line of code,
without any unit tests

Technical Debt
Delphi software older than a few decades
– Stuck with Delphi 7 / 2007
– Stuck with a single database
– Stuck with unmaintained UI component(s)
– Stuck with millions of line of code,
without any unit tests

Technical Debt
Legacy Systems induce a technical debt
Like a financial debt,
incurs interest payment
• Extra efforts in any future
development
• Higher maintenance costs

Technical Debt
Marco Geuze said this morning
that legacy code is not Technical Debt

Technical Debt
it may not be 100% debt
but it certainly has some debt

Technical Debt
but of course, it is working
and has domain/business knowledge

Software Seams
A place where
you can alter your program behavior
without editing in that place

Software Seams
Refactoring to isolate seams via interfaces
1. Know your subject
2. Identify responsibilities big picture
3. Study data structures
4. Break out huge functions
5. Break out giant classes iterative process
6. Encapsulate global references
7. Testing is everything

Software Seams
1. Know your subject
2. Identify responsibilities big picture
3. Study data structures
4. Break out huge functions
5. Break out giant classes iterations
6. Encapsulate global references
7. Testing is everything

Software Seams
• AI tools may help
with iterations

Software Seams
From interface comes abstraction
• SOLID principles
• SOA and (Micro)Services
• Database agnostic
• Testing/mocking

Test Driven Design
Coding is an Iterative process
• Even up to the management level
(projects)
• Ensure each step won’t break any
previous step
• Testing should be part of this process

Test Driven Design
Test Driven Design (TDD)
means “iterate from tests into tests”

Test Driven Design
TDD means “let tests pass”
1. Write the test
2. Fails the test
3. Implements the feature
4. Fails the test ? Drink a coffee and go to 3.
5. Pass the test and all previous tests
6. Continue to the next feature

Test Driven Design
Test Driven Design main benefits
 Ensure we didn’t break anything
 Expect we won’t break anything

Test Driven Design
• Test Driven Design collateral benefits
• Define the types and API early
• Refine the expectations ASAP
• Document the API before implementing
• Can mock the UI before implementing
• Tests as specification

Test Driven Design
• Mocking / Stubbing
"The Art of Unit Testing“
(Osherove, Roy - 2009)
– The power of fake objects
Stubs and Mocks

Test Driven Design
"The Art of Unit Testing" (Osherove, Roy - 2009)
– Stubs are fake objects
implementing a given contract
and returning pre-arranged responses
• They just let the test pass
• They “emulate” some behavior
(e.g. a database)

Test Driven Design
"The Art of Unit Testing" (Osherove, Roy - 2009)
– Mocks are fake objects like stubs
which will verify if an interaction occurred
or not
• They help decide if a test failed or passed
• There should be only one mock per test

Test Driven Design
TLoginController = class(TInterfacedObject, ILoginController)
protected
fUserRepository: IUserRepository;
fSmsSender: ISmsSender;
public
constructor Create(const aUserRepository: IUserRepository;
const aSmsSender: ISmsSender);
procedure ForgotMyPassword(const UserName: RawUtf8);
end;
constructor TLoginController.Create(const aUserRepository: IUserRepository; const
aSmsSender: ISmsSender);
begin // dependencies injection in constructor
fUserRepository := aUserRepository;
fSmsSender := aSmsSender;
end;

Test Driven Design
IUserRepository = interface(IInvokable)
['{B21E5B21-28F4-4874-8446-BD0B06DAA07F}']
function GetUserByName(const Name: RawUtf8): TUser;
procedure Save(const User: TUser);
end;
ISmsSender = interface(IInvokable)
['{8F87CB56-5E2F-437E-B2E6-B3020835DC61}']
function Send(const Text, Number: RawUtf8): boolean;
end;

Test Driven Design
procedure TLoginController.ForgotMyPassword(
const UserName: RawUtf8);
var U: TUser;
begin
U := fUserRepository.GetUserByName(UserName);
U.Password := Int32ToUtf8(Random31);
if fSmsSender.Send('Your new password is ' +
U.Password, U.MobilePhoneNumber) then
fUserRepository.Save(U);
end;

Expect – Run – Verify pattern
procedure TMyTest.ForgotMyPassword;
var sms: ISmsSender;
repo: IUserRepository;
begin
TInterfaceStub.Create(ISmsSender, sms).
Returns('Send', [true]);
TInterfaceMock.Create(IUserRepository, repo, self).
ExpectsCount('Save', qoEqualTo, 1);
with TLoginController.Create(repo, sms) do
try
ForgotMyPassword('toto');
finally
Free;
end;

Run – Verify (aka “Test spy”)
procedure TMyTest.ForgotMyPassword;
var sms: ISmsSender;
repo: IUserRepository;
spy: TInterfaceMockSpy;
begin
TInterfaceStub.Create(ISmsSender, sms).Returns('Send', [true]);
spy := TInterfaceMockSpy.Create(IUserRepository, repo, self);
with TLoginController.Create(repo, sms) do
try
ForgotMyPassword('toto');
finally
Free;
end;
spy.Verify('Save');

Test Driven Design
Mocking / Stubbing - another features
• Return complex values (e.g. a DTO)
• Use a delegate to create a stub/mock
• Using named or indexed variant parameters
• Using JSON array of values

Test Driven Design
Mocking / Stubbing - another features
• Access the test case when mocking
• Trace and verify the calls
• With a fluent interface
• Log all calls (as JSON)

mormot2tests
Where I spend most of my time:
 Write a new feature test
 Implement the feature
 Debug to let it pass
 Run all other tests

mormot2tests
Console application
• Part of mORMot repository
• Delphi and FPC
• On all supported systems (LUTI)

mormot2tests
Several kind of tests
 Unitary tests
 Integration tests
 Stability tests (threads, OS…)
 Performance tests

mormot2tests
“LUTI” nightly integration tests
https://luti.tranquil.it/listfolder/b469
db22-f483-45c2-90a8-
f640c1eb8457

mormot2tests
SHOW ME THE CODE !

To Visit the marmots
https://cauterets.site

Test Driven Development with mORMot 2 with Delphi and FPC

More Related Content

Similar to Test Driven Development with mORMot 2 with Delphi and FPC

More from Arnaud Bouchez

Recently uploaded

Test Driven Development with mORMot 2 with Delphi and FPC