Test Driven Development with mORMot 2 with Delphi and FPC

Every project should have tests. Every project should start by writing tests. In a nutshell, this is what Test Driven Development implies.

In this interactive session, we will try to define which paths are possible to properly include tests to new or existing projects.

As a practical example, we will see how the mORMot Open Source project is actually test-driven, via unit tests, regression tests, and performance tests.

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

2. 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

3. 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

4. Test Driven Design
(aka TDD)
with mORMot 2

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

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

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

8. Technical Debt

9. Technical Debt

10. 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

11. 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

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

13. Technical Debt
Marco Geuzesaid this morning
that legacy code is not Technical Debt

14. Technical Debt
Marco Geuzesaid this morning
that legacy code is not Technical Debt
it may not be 100% debt
but it certainly has some debt

15. Technical Debt
Marco Geuzesaid this morning
that legacy code is not Technical Debt
but of course, it is working
and has domain/business knowledge

16. Technical Debt

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

18. Software Seams

19. Software Seams

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

21. 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

22. 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 iterations
6.Encapsulate global references
7.Testing is everything

23. Software Seams
Refactoring to isolate seams via interfaces
•AI tools may help
with iterations

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

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

26. Test Driven Design

27. Test Driven Design

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

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

30. 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

31. Test Driven Design
Test Driven Designmain benefits
Ensure we didn’tbreak anything
Expect we won’tbreak anything

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

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

34. Test Driven Design
•Mocking / Stubbing
"The Art of Unit Testing" (Osherove, Roy -2009)
–Stubsare 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)

35. Test Driven Design
•Mocking / Stubbing
"The Art of Unit Testing" (Osherove, Roy -2009)
–Mocksare 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 onemock per test

36. Mocks and
Stubs

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

38. Test Driven Design
IUserRepository= interface(IInvokable)
['{B21E5B21-28F4-4874-8446-BD0B06DAA07F}']
functionGetUserByName(constName: RawUtf8): TUser;
procedureSave(constUser: TUser);
end;
ISmsSender= interface(IInvokable)
['{8F87CB56-5E2F-437E-B2E6-B3020835DC61}']
functionSend(constText, Number: RawUtf8): boolean;
end;

39. Test Driven Design
procedureTLoginController.ForgotMyPassword(
constUserName: RawUtf8);
varU: TUser;
begin
U := fUserRepository.GetUserByName(UserName);
U.Password:= Int32ToUtf8(Random31);
iffSmsSender.Send('Your new password is ' +
U.Password, U.MobilePhoneNumber) then
fUserRepository.Save(U);
end;

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

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

42. 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

43. 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)

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

45. mormot2tests

46. mormot2tests

47. 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

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

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

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

51. mormot2tests
SHOW ME THE CODE !

52. To Visit the marmots
https://cauterets.site

53. Questions?