When writing Object-Oriented software these days, few developers doubt the benefits of TDD. The Software Craftsmanship movement even goes one step further, and says that it is just plain irresponsible to write software without this tool. More and more projects are using Functional programming languages, though, and TDD is not so common in this side of the software development world. Maybe TDD doesn’t make sense outside Object-Oriented software? After experimenting with the TDD mindset and Functional languages in real-world projects, my experience is that those also benefit a lot from using tests as design aid. In this talk, let’s investigate what is generally accepted as good practices in Functional Programming and how to use TDD to take us there, with examples in Clojure.

1. Better Functional Design
Through Test-Driven
Development
Phil Calçado - SoundCloud
@pcalcado
http://philcalcado.com
Thursday, March 8, 12

2. ohai!
i’m phil.
Thursday, March 8, 12

3. i work here:
Thursday, March 8, 12

4. Thursday, March 8, 12

5. and so should you.
Thursday, March 8, 12

6. http://bit.ly/work-at-soundcloud
Thursday, March 8, 12

7. Better Functional Design
Through Test-Driven
Development
Phil Calçado - SoundCloud
@pcalcado
http://philcalcado.com
Thursday, March 8, 12

8. better? what’s good
functional design,
to begin with?
Better Functional Design
Through Test-Driven
Development
Phil Calçado - SoundCloud
@pcalcado
http://philcalcado.com
Thursday, March 8, 12

9. I have no idea.
Thursday, March 8, 12

10. how I got started with objects
Thursday, March 8, 12

11. Thursday, March 8, 12

12. Thursday, March 8, 12

13. Thursday, March 8, 12

14. Thursday, March 8, 12

15. Thursday, March 8, 12

16. Thursday, March 8, 12

17. Thursday, March 8, 12

18. Thursday, March 8, 12

19. Thursday, March 8, 12

20. Thursday, March 8, 12

21. Relationships Between BOUNDED CONTEXTS
Shared Kernel
Thursday, March 8, 12

22. Gzs%ef.
.
. . . . .
, . . .
. . . .
. . . . . .
. . . .
. . .
. . ,
. . . .
. . . . . .
. .
. .
. . . .
. . . .
. . . . . .
Permission to copy without fee all or part of this materinl is
granted prowded that the topics are not mada or distributed for
direct commcrciol advantage, the ACM copyright notice ond tho
lillc of the publication and its dare appear. and notice is given
that copying is by permission of the Association for Computing
Machinery. To copy othcrwisc, or to republish. requires B fee
and/or specific pornlission.
HOPL-11/4/93/MA,USA
o 1993 ACM 0-89791.571.2/93/0004/0069...$1.50
2
:LJ 2
.x E
.m 8
al
:5 a
.6
Thursday, March 8, 12

23. Programming R. Morris
Techniques Editor
On the Criteria To Be
o 1993 ACM 0-89791.571.2/93/0004/0069...$1.50
and/or specific
that copying
HOPL-11/4/93/MA,USA
Machinery.
lillc of the publication
direct commcrciol
granted
Permission
Gzs%ef.
.
.
.
.
.
.
.
.
,
. . . . .
Used in Decomposing
.
.
.
.
.
.
.
.
.
.
.
.
prowded
.
.
.
.
.
.
.
.
.
.
Systems into Modules
.
.
.
.
,
.
.
.
.
.
to copy without
To copy othcrwisc,
is by permission
.
.
.
.
.
.
.
pornlission.
.
.
.
.
.
that the topics
advantage,
D.L. Parnas
Carnegie-Mellon University
and its dare appear.
fee all or part of this materinl
the ACM copyright
of the Association
are not mada or distributed
or to republish.
This paper discusses modularization as a mechanism Introduction
and notice is given
for improving the flexibility and comprehensibility of a
for Computing
notice ond tho
A lucid statement o f the philosophy o f m o d u l a r
requires
system while allowing the shortening of its development
time. The effectiveness of a "modularization" is p r o g r a m m i n g can be f o u n d in a 1970 t e x t b o o k on the
dependent upon the criteria used in dividing the system design o f system p r o g r a m s by G o u t h i e r and P o n t [1,
B fee
into modules. A system design problem is presented and ¶I0.23], which we quote below: 1
for
is
both a conventional and unconventional decomposition A well-defined segmentation of the project effort ensures
are described. It is shown that the unconventional system modularity. Each task forms a separate, distinct program
decompositions have distinct advantages for the goals module. At implementation time each module and its inputs and
outputs are well-defined, there is no confusion in the intended
outlined. The criteria used in arriving at the decom- interface with other system modules. At checkout time the in-
positions are discussed. The unconventional decomposi- tegrity of the module is tested independently; there are few sche-
tion, if implemented with the conventional assumption duling problems in synchronizing the completion of several tasks
before checkout can begin. Finally, the system is maintained in
that a module consists of one or more subroutines, will modular fashion; system errors and deficiencies can be traced to
be less efficient in most cases. An alternative approach specific system modules, thus limiting the scope of detailed error
.6
:5
:LJ
.m
.x
al
to implementation which does not have this effect is searching.
sketched. Usually nothing is said a b o u t the criteria to be used
Key Words and Phrases: software, modules, in dividing the system into modules. This paper will
a
2
8
E
2
modularity, software engineering, KWIC index, discuss that issue and, by means o f examples, suggest
software design some criteria which can be used in d e c o m p o s i n g a
CR Categories: 4.0 system into modules.
A Brief Status Report
The m a j o r a d v a n c e m e n t in the area o f m o d u l a r
p r o g r a m m i n g has been the development o f coding
techniques and assemblers which (l) allow one module
to be written with little knowledge o f the code in
a n o t h e r module, and (2) allow modules to be reas-
Copyright @ 1972, Association for Computing Machinery, Inc. sembled and replaced without reassembly o f the whole
General permission to republish, but not for profit, all or part
of this material is granted, provided that reference is made to this system. This facility is extremely valuable for the
publication, to its date of issue, and to the fact that reprinting production o f large pieces o f code, but the systems m o s t
privileges were granted by permission of the Association for Com- often used as examples o f p r o b l e m systems are highly-
puting Machinery.
Author's address: Department of Computer Science, Carnegie- modularized p r o g r a m s and make use o f the techniques
Mellon University, Pittsburgh, PA 15213. mentioned above.
1 Reprinted by permission of Prentice-Hall, Englewood
Cliffs, N.J.
1053 Communications December 1972
of Volume 15
the ACM Number 12
Thursday, March 8, 12

24. Programming R. Morris
Techniques Editor
On the Criteria To Be
o 1993 ACM 0-89791.571.2/93/0004/0069...$1.50
and/or specific
that copying
HOPL-11/4/93/MA,USA
Machinery.
lillc of the publication
direct commcrciol
granted
Permission
Gzs%ef.
.
.
.
.
.
.
.
.
,
. . . . .
Used in Decomposing
.
.
.
.
.
.
.
.
.
.
.
.
prowded
.
.
.
.
.
.
.
.
.
.
Type Systems
Systems into Modules
.
.
.
.
,
.
.
.
.
.
to copy without
To copy othcrwisc,
is by permission
.
.
.
.
.
.
.
pornlission.
.
.
.
.
.
that the topics
advantage,
D.L. Parnas
Luca Cardelli
Carnegie-Mellon University
and its dare appear.
Microsoft Research
fee all or part of this materinl
the ACM copyright
of the Association
are not mada or distributed
or to republish.
1 Introduction
This paper discusses modularization as a mechanism Introduction
and notice is given
for improving the flexibility and comprehensibility of a
type system f prevent the occurrence r
The fundamental purpose of alucid statement iso tothe philosophy o f m o d u l aof execution errors dur-
for Computing
notice ond tho
A
requires
system while allowing the shortening of its development
ing the running of a program.m m i n g informalostatement motivates kthe study of type systems, but
time. The effectiveness of a "modularization" is p r o g r a This can be f u n d in a 1970 t e x t b o o on the
dependent upon the criteria used in dividing clarification. Its accuracy depends, rfirst of all, u t h i theand P o nsubtle issue of what consti-
requires the system design o f system p r o g a m s by G o on e r rather t [1,
B fee
into modules. A system design problem is presented and ¶I0.23], which we quote below: 1
tutes an execution error, which we will discuss in detail. Even when that is settled, the absence
for
is
both a conventional and unconventional decomposition A well-defined segmentation of the project effort ensures
are described. It is shown that theof execution errors is a system modularity. Each task formssuch a propertyprogram for all of the program
unconventional nontrivial property. When a separate, distinct holds
decompositions have distinct advantagesthat the goals expressed within a programming language, weinputs that the language is type
runs for can be module. At implementation time each module and its and
outputs are well-defined, there is no confusion in the sayintended
outlined. The criteria used in arriving at the decom-
sound. It turns out that tegrity of the module is tested independently; there are few sche-
positions are discussed. The unconventional decomposi-
interface amount of careful analysis is required to avoid false and embar-
a fair with other system modules. At checkout time the in-
tion, if implemented with the conventional claims of type soundness for in synchronizing the completion of several tasks
rassing assumption duling problems programming languages. As a consequence, the classifica-
before checkout can begin. Finally, the system is maintained in
tion, description, and study of type systemserrors and deficiencies a formal discipline.
that a module consists of one or more subroutines, will modular fashion; system has emerged as can be traced to
be less efficient in most cases. An alternative approach specific system modules, thus limiting the scope of detailed error
.6
:5
:LJ
.m
to implementation which does not have The effect is
this formalization of type systems requires the development of precise notations and defi-
.x
al
searching.
sketched. nitions, and the detailed proof of formal propertiesu that give confidence in the appropriateness
Usually nothing is said a b o t the criteria to be used
Key Words and Phrases: software, modules,
of the definitions. Sometimes the discipline becomes rather This paperOne should always remem-
in dividing the system into modules. abstract. will
a
2
8
E
2
modularity, software engineering, KWIC index,
software design ber, though, that the basic motivation is pragmatic: theoabstractions have arisen out of necessity
discuss that issue and, by means f examples, suggest
some criteria which can be used in d e c o m p o s i n g a
CR Categories: 4.0 and can usually be related directly modules.
system into to concrete intuitions. Moreover, formal techniques need not
be applied in full in order to be useful and influential. A knowledge of the main principles of
type systems can help inAavoiding obvious and not so obvious pitfalls, and can inspire regularity
Brief Status Report
and orthogonality in language design.
When properly developed,mtype systemsmprovidethe area o f m o d u l awith which to judge the
The a j o r a d v a n c e e n t in conceptual tools r
p r o g r a m m i n g has been the development o f coding
adequacy of important aspects of language definitions.(l) allow one module descriptions often fail
techniques and assemblers which
Informal language
to specify the type structure ofwritten with in sufficient detail to allow unambiguous implemen-
to be a language little knowledge o f the code in
tation. ItMachinery, Inc.
Copyright @ 1972, Association for Computing
often happens athath e r module,compilers allowthe same language implement slightly dif-
n o t different and (2) for modules to be reas-
sembled and replaced without reassembly o f the whole
General permission to republish, but not for profit, all or part Moreover, many language definitions have been found to be type unsound,
ferent type systems.
of this material is granted, provided that reference is made to this system. This facility is extremely valuable for the
production o f large it is judged acceptable by typechecker. Ideally, for-
publication, to its date of issue, and allowing that reprinting to crash even though pieces o f code, but the systemsam o s t
to the fact a program
privileges were granted by permission of the Association for Com-
puting Machinery. mal type systems shouldoftenpart ofas examples o f pofballm systems are highly- languages. This way,
be used the definition r o l e typed programming
Author's address: Department of Computer Science, Carnegie- modularized p r o g r a m s and make use o f the techniques
Mellon University, Pittsburgh, PA 15213.typechecking algorithms could beabove.
mentioned measured unambiguously against precise specifications and,
if at all possible and feasible, whole languages couldPrentice-Hall, to be type sound.
1 Reprinted by permission of be shown Englewood
Cliffs, N.J.
In this introductory section we present an informal nomenclature for typing, execution er-
1053 rors, and related concepts. We discuss the expected properties and benefits of type systems, and
Communications December 1972
we review how type systems can be formalized. Volume 15
of
the ACM The terminology used in the introduction is not
Number 12
completely standard; this is due to the inherent inconsistency of standard terminology arising
from various sources. In general, we avoid the words type and typing when referring to run time
concepts; for example we replace dynamic typing with dynamic checking and avoid common
but ambiguous terms such as strong typing. The terminology is summarized in the Defining
Terms section.
CRC Handbook of Computer Science and Engineering, 2nd Edition, Ch. 97, Wednesday, February 25, 2004, 8:00 pm. © CRC Press. 1
Thursday, March 8, 12

25. Programming R. Morris
Techniques Editor
On the Criteria To Be
o 1993 ACM 0-89791.571.2/93/0004/0069...$1.50
and/or specific
that copying
HOPL-11/4/93/MA,USA
Machinery.
lillc of the publication
direct commcrciol
granted
Permission
Gzs%ef.
.
.
.
.
.
.
.
.
,
. . . . .
Used in Decomposing
.
.
.
.
.
.
.
.
.
.
.
.
prowded
.
.
.
.
.
.
.
.
.
.
Type Systems
Systems into Modules
.
.
.
.
,
.
.
.
.
.
to copy without
To copy othcrwisc,
is by permission
.
.
.
.
.
.
.
pornlission.
.
.
.
.
.
that the topics
advantage,
D.L. Parnas
Luca Cardelli
Carnegie-Mellon University
and its dare appear.
Microsoft Research
fee all or part of this materinl
the ACM copyright
of the Association
are not mada or distributed
or to republish.
1 Introduction
This paper discusses modularization as a mechanism Introduction
and notice is given
for improving the flexibility and comprehensibility of a
type system f prevent the occurrence r
The fundamental purpose of alucid statement iso tothe philosophy o f m o d u l aof execution errors dur-
for Computing
notice ond tho
A
requires
system while allowing the shortening of its development
ing the running of a program.m m i n g informalostatement motivates kthe study of type systems, but
time. The effectiveness of a "modularization" is p r o g r a This can be f u n d in a 1970 t e x t b o o on the
dependent upon the criteria used in dividing clarification. Its accuracy depends, rfirst of all, u t h i theand P o nsubtle issue of what consti-
requires the system design o f system p r o g a m s by G o on e r rather t [1,
B fee
into modules. A system design problem is presented and ¶I0.23], which we quote below: 1
tutes an execution error, which we will discuss in detail. Even when that is settled, the absence
for
is
both a conventional and unconventional decomposition A well-defined segmentation of the project effort ensures
are described. It is shown that theof execution errors is a system modularity. Each task formssuch a propertyprogram for all of the program
unconventional nontrivial property. When a separate, distinct holds
decompositions have distinct advantagesthat the goals expressed within a programming language, weinputs that the language is type
runs for can be module. At implementation time each module and its and
outputs are well-defined, there is no confusion in the sayintended
outlined. The criteria used in arriving at the decom-
sound. It turns out that tegrity of the module is tested independently; there are few sche-
positions are discussed. The unconventional decomposi-
interface amount of careful analysis is required to avoid false and embar-
a fair with other system modules. At checkout time the in-
tion, if implemented with the conventional claims of type soundness for in synchronizing the completion of several tasks
rassing assumption duling problems programming languages. As a consequence, the classifica-
before checkout can begin. Finally, the system is maintained in
tion, description, and study of type systemserrors and deficiencies a formal discipline.
that a module consists of one or more subroutines, will modular fashion; system has emerged as can be traced to
be less efficient in most cases. An alternative approach specific system modules, thus limiting the scope of detailed error
.6
:5
:LJ
.m
to implementation which does not have The effect is
this formalization of type systems requires the development of precise notations and defi-
.x
al
searching.
sketched. nitions, and the detailed proof of formal propertiesu that give confidence in the appropriateness
Usually nothing is said a b o t the criteria to be used
Key Words and Phrases: software, modules,
of the definitions. Sometimes the discipline becomes rather This paperOne should always remem-
in dividing the system into modules. abstract. will
a
2
8
E
2
modularity, software engineering, KWIC index,
software design ber, though, that the basic motivation is pragmatic: theoabstractions have arisen out of necessity
discuss that issue and, by means f examples, suggest
some criteria which can be used in d e c o m p o s i n g a
CR Categories: 4.0 and can usually be related directly modules.
system into to concrete intuitions. Moreover, formal techniques need not
be applied in full in order to be useful and influential. A knowledge of the main principles of
type systems can help inAavoiding obvious and not so obvious pitfalls, and can inspire regularity
Brief Status Report
and orthogonality in language design.
When properly developed,mtype systemsmprovidethe area o f m o d u l awith which to judge the
The a j o r a d v a n c e e n t in conceptual tools r
p r o g r a m m i n g has been the development o f coding
adequacy of important aspects of language definitions.(l) allow one module descriptions often fail
techniques and assemblers which
Informal language
to specify the type structure ofwritten with in sufficient detail to allow unambiguous implemen-
to be a language little knowledge o f the code in
tation. ItMachinery, Inc.
Copyright @ 1972, Association for Computing
often happens athath e r module,compilers allowthe same language implement slightly dif-
n o t different and (2) for modules to be reas-
sembled and replaced without reassembly o f the whole
General permission to republish, but not for profit, all or part Moreover, many language definitions have been found to be type unsound,
ferent type systems.
of this material is granted, provided that reference is made to this system. This facility is extremely valuable for the
production o f large it is judged acceptable by typechecker. Ideally, for-
publication, to its date of issue, and allowing that reprinting to crash even though pieces o f code, but the systemsam o s t
to the fact a program
privileges were granted by permission of the Association for Com-
puting Machinery. mal type systems shouldoftenpart ofas examples o f pofballm systems are highly- languages. This way,
be used the definition r o l e typed programming
Author's address: Department of Computer Science, Carnegie- modularized p r o g r a m s and make use o f the techniques
Mellon University, Pittsburgh, PA 15213.typechecking algorithms could beabove.
mentioned measured unambiguously against precise specifications and,
if at all possible and feasible, whole languages couldPrentice-Hall, to be type sound.
1 Reprinted by permission of be shown Englewood
Cliffs, N.J.
In this introductory section we present an informal nomenclature for typing, execution er-
1053 rors, and related concepts. We discuss the expected properties and benefits of type systems, and
Communications December 1972
we review how type systems can be formalized. Volume 15
of
the ACM The terminology used in the introduction is not
Number 12
completely standard; this is due to the inherent inconsistency of standard terminology arising
from various sources. In general, we avoid the words type and typing when referring to run time
concepts; for example we replace dynamic typing with dynamic checking and avoid common
but ambiguous terms such as strong typing. The terminology is summarized in the Defining
Terms section.
CRC Handbook of Computer Science and Engineering, 2nd Edition, Ch. 97, Wednesday, February 25, 2004, 8:00 pm. © CRC Press. 1
Thursday, March 8, 12