Functional programming returned to the main stream after long years of hiatus. Languages like Haskell, Coq, Agda promise us better code just by using their advanced type systems. Although the dreaded null hides around every corner in Java is it possible to structure our code in a way that illegal states are not representable? Can the type system alone be enough for us to be sure that the code is correct? Do types mean that no tests are required? During this talk, we will look at examples of code where the types control what code can be written (and there is no other way to do it). We will explore the possibilities to lower the number of unit tests or avoid some of them completely just by using the type system alone. We will try to find an answer what stronger type systems can give us, what are dependent types and how could they look in Java.

1. < Do I need tests when I have the
compiler? >
Andrzej Jóźwiak

2. https://twitter.com/unclebobmartin/status/1135894370165710848

3. https://twitter.com/unclebobmartin/status/1204093210307379200

4. https://xkcd.com/386/

5. https://twitter.com/unclebobmartin/status/1204068066679615489

6. “Given a good test suite the
return on investment
simply does not justify the
use of static typing”
Jay Fields

7. “On the whole, I’m inclined to say that
when in doubt, make a new type. It
usually requires little effort but often
provides surprising results.”
Martin Fowler
https://www.martinfowler.com/ieeeSoftware/whenType.pdf

8. “In 5 years we will view
compilation as the weakest
form of unit testing”
Stuart Halloway

9. “as the types get more
generic, the tests become
more redundant”
Mark Seeman

10. “Code that's hard to test in isolation is poorly
designed, goes a common TDD maxim (…) It's from
this unfortunate maxim that much of the test-
induced design damage flows (…) Code that is
warped out of shape solely to accomodate testing
objectives.”
David Heinemeier Hansson
https://dhh.dk/2014/test-induced-design-damage.html

11. “Make illegal states
unrepresentable”
Yaron Minsky

12. What do we test?

13. Input values correctness
Are values in range?
Are values satisfying the constraints?
Are values having a valid structure?

14. Is the domain of the function correct?
Is the domain too large?
Is this function total?
Integer divide(Integer a, Integer b) {
return a / b;
}
https://git.io/Jvvvy

15. Narrowing the domain of the function
Partial function becomes total
class NonZeroInteger extends Number {
private final Integer value;
// methods and constructor removed for brevity
static Optional<NonZeroInteger> of(Integer value) {
if (value == 0)
return Optional.empty();
return Optional.of(new NonZeroInteger(value));
}
}
Integer divide(Integer a, NonZeroInteger b) {
return a / b.intValue();
}
https://git.io/Jvvvy

16. Good not only for a simple division
Helps lower the amount of tests?
// from:
<A> A getFirst(List<A> list)
// to:
<A> A getFirst(NonEmptyList<A> list)
// or (probably well known approach):
<A> A getFirst(List<A> list, A default)
// from:
<A> List<A> take(Integer amount, List<A> list)
// to:
<A> List<A> take(Natural amount, List<A> list)
https://git.io/Jvvv9

17. Narrowing the domain of types used by our model
Skipping tests for correctness of the model
// from:
class Order {
private final List<Tickets> tickets;
// ...
}
// to:
class Order {
private final NonEmptyList<Tickets> tickets;
// ...
}

18. Output values correctness
Given correct inputs
Are values in range?
Are values satisfying the constraints?
Are values having a valid structure?

19. Is the codomain of the function correct?
Is the codomain too small?
Integer divide(Integer a, Integer b) {
return a / b;
}
https://git.io/JvvvH

20. Expand the codomain
The cardinality of the resulting type is a + 1
What was done by NonZeroInt now is baked into
the divide function
Optional<Integer> divide(Integer a, Integer b) {
if (b == 0)
return Optional.empty()
return Optional.empty(a / b);
}
https://git.io/JvvvH

21. // from:
<A> A getFirst(List<A> list)
// to:
<A> Optional<A> getFirst(List<A> list)
// from:
User getUser(Database db, Long id)
// to:
Optional<User> getUser(Database db, Long id)

22. Illegal states not happening
Are our models correctly instantiated?
Are our models correctly used?
Are our models even correct?

23. enum ConnectionState {
CONNECTING,
CONNECTED,
DISCONNECTED
}
class ConnectionInfo {
private ConnectionState connectionState;
private InetAddress serverAddress;
private long lastPingTimeInMs;
private long connectionStartTimeInMs;
private long connectionStopTimeInMs;
private String sessionId;
}
Good enough?
https://git.io/JeADW

24. enum ConnectionState {
CONNECTING,
CONNECTED,
DISCONNECTED
}
class SessionId {}
class ConnectionInfo {
private ConnectionState connectionState;
private InetAddress serverAddress;
private Optional<Duration> lastPingTime;
private Optional<LocalTime> connectionStartTime;
private Optional<LocalTime> connectionStopTime;
private Optional<SessionId> sessionId;
}
Better or not?
https://git.io/JeAD0

25. class SessionId {}
abstract class ConnectionState {
class Connecting extends ConnectionState {
LocalTime connectionStartTime;
}
class Connected extends ConnectionState {
SessionId sessionId;
Optional<Duration> lastPingTime;
}
class Disconnected extends ConnectionState {
LocalTime connectionStopTime;
}
}
class ConnectionInfo {
private InetAddress serverAddress;
private ConnectionState connectionState;
}
https://git.io/JeADE

26. Side effects caused
Are effects performed?
Are effects correctly ordered?
Are effects finished?

27. class Departure {}
class Destination {}
class Route {
Departure departure;
Destination destination;
// methods and constructor removed for brevity
}
void modifyDestination(Route route)
https://git.io/JvvvQ
What do we need to test for?
Should we check if departure is left untouched?
Should we check other fields?

28. // everything is now immutable
// suspension of disbelief here :-)
class Departure {}
class Destination {}
class Route {
final Departure departure;
final Destination destination;
// methods and constructor removed for brevity
}
Route modifyDestination(final Route route)
https://git.io/JvvvQ
No side effects = no problem :)

29. Model handling
Are we always exhausting every option?

30. class Account {
// other fields etc
Optional<DrivingProfile> drivingProfile;
}
class DbAccount {
// ...
Optional<DbDrivingProfileId> drivingProfile;
}
// function interested only in Accounts with a Driving Profile
List<Account> getAccountsWithSameProfile(Account account)
Optional means a lot of checks
Similar models mean a lot of boilerplate

31. class Account<A> {
// other fields etc
A profile;
}
// possibilities:
-- Account<DrivingProfile> // account with a profile
-- Account<Void> // account without a profile
-- Account<DbDrivingProfileId> // account with db foreign key
-- Account<Optional<DrivingProfile>>
// function interested only in Accounts with a Driving Profile
List<Account<DrivingProfile>> getAWDP(Account<DrivingProfile> account)

32. We not only need the types, we
need the RIGHT types!

33. https://twitter.com/cbirchall/status/1209156343904587779

34. https://git.io/JeADM

35. But do we need tests for
everything?

36. <A> A foo(A a)
// or:
<A, B> Function<B, A> bar(A a)
What do we know about these functions?
How many implementations there are?
Do we need to test them?
Would it be easier to understand what are they doing
if we will give them proper names?

37. <A> A identity(A a) {
return a;
}
<A, B> Function<B, A> constant(A a) {
return b -> a;
}
Let’s imagine null does not exist!

38. A * (B | C)
is equivalent to
(A * B) | (B * C)
Can we implement this incorrectly?

39. class Product<A, B> {
A first;
B second;
// methods and constructor removed for breavity
}
abstract class Sum<A, B> {
abstract <C> C match(Function<A, C> onLeft, Function<B, C> onRight);
public static class Left<A, B> extends Sum<A, B> {
A left;
<C> C match(Function<A, C> onLeft, Function<B, C> onRight) {
return onLeft.apply(left);
}
}
public static class Right<A, B> extends Sum<A, B> {
B right;
<C> C match(Function<A, C> onLeft, Function<B, C> onRight) {
return onRight.apply(right);
}
}
}

40. <A, B, C> Sum<Product<A, B>, Product<A, C>> convert(Product<A, Sum<B, C>> product) {
return product.second.match(
(B left) -> new Sum.Left<>(new Product<>(product.first, left)),
(C right) -> new Sum.Right<>(new Product<>(product.first, right))
);
}

41. <A> List<A> reverse(List<A> a)
What do we know about this function?
How many implementations there are?
How should we test it?
Does the function have some interesting
properties?
https://people.mpi-sws.org/~dreyer/tor/papers/wadler.pdf

42. https://www.amazon.com/Lectures-Curry-Howard-Isomorphism-Foundations-Mathematics/dp/0444520775

43. Gentle introduction to
dependent type!
I promise! And no Math!

44. List<Integer><10> // Integer list with values above 10
List<Integer><10> list1 = Arrays.asList(11, 12); // compiles
List<Integer><10> list2 = Arrays.asList(1, 2); // does not compile
In Java!*
*with invented syntax!

45. And there are a lot of them!
Proof assistants

46. https://isabelle.in.tum.de/
https://coq.inria.fr/
https://www.fstar-lang.org/ https://wiki.portal.chalmers.se/agda
/
https://www.idris-
lang.org/
~15 other

47. Like enterprise level software!?!
Anything useful proven?

48. The world's first operating-system kernel with an end-to-end proof of
implementation correctness and security enforcement is available as open
source
We have already covered the properties that are proved directly: functional
correctness, integrity, and confidentiality. These are high-level properties that every
OS should provide, that very few manage to provide, and that no OS has better
evidence for than seL4. The formal proof of functional correctness implies the
absence of whole classes of common programming errors. Provided our
assumptions above are true, some of these excluded common errors are: Buffer
overflows, Null pointer dereferences, Pointer errors in general, Memory leaks,
Arithmetic overflows and exceptions, Undefined behaviour.
seL4 microkernel
https://sel4.systems/

49. CompCert C is a compiler for the C programming language. Its intended use is
the compilation of life-critical and mission-critical software written in C and
meeting high levels of assurance (...)
What sets CompCert C apart from any other production compiler, is that it is formally
verified, using machine-assisted mathematical proofs, to be exempt from
miscompilation issues. In other words, the executable code it produces is proved to
behave exactly as specified by the semantics of the source C program.
CompCert verified C compiler
http://compcert.inria.fr/
Do you trust your compiler?

50. The HTTPS ecosystem (HTTPS and TLS protocols, X.509 public key
infrastructure, crypto algorithms) is the foundation on which Internet security
is built. Unfortunately, this ecosystem is brittle, with headline-grabbing attacks
such as FREAK and LogJam and emergency patches many times a year. (...)
Project Everest addresses this problem by constructing a high-performance,
standards-compliant, formally verified implementation of components in HTTPS
ecosystem, including TLS, the main protocol at the heart of HTTPS, as well as the
main underlying cryptographic algorithms such as AES, SHA2 or X25519 (...)
Formally verified HTTPS
https://project-everest.github.io/

51. https://github.com/idris-hackers/idris-demos/tree/master/Invaders
Space Invaders verified?

52. Are you sure?
No one is really doing it!
https://github.com/arrow-kt/arrow-meta/tree/sv-test-proofs/prelude/src/main/kotlin/arrow
https://github.com/ticki/rfcs/blob/pi-types-2/text/0000-pi-types.md

54. - https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html
- http://blog.cleancoder.com/uncle-bob/2017/01/13/TypesAndTests.html
- http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html
- https://blog.ploeh.dk/2018/07/09/typing-and-testing-problem-23/
- https://en.m.wikipedia.org/wiki/Curry-Howard_correspondence
- http://www.cse.chalmers.se/~peterd/papers/DependentTypesAtWork.pdf
- http://www.pamelazave.com/chord.html
- https://www.adacore.com/sparkpro
- https://wiki.portal.chalmers.se/agda/pmwiki.php
- https://www.idris-lang.org/
- https://coq.inria.fr/
Bibliography

55. Thank you!