Better Functional Design               Through Test-Driven                   Development                        Phil Calça...
ohai!                           i’m phil.Thursday, March 8, 12
i work here:Thursday, March 8, 12
Thursday, March 8, 12
and so should you.Thursday, March 8, 12
http://bit.ly/work-at-soundcloudThursday, March 8, 12
Better Functional Design               Through Test-Driven                   Development                        Phil Calça...
better? what’s good                                  functional design,                                    to begin with? ...
I have no idea.Thursday, March 8, 12
how I got started with objectsThursday, March 8, 12
Thursday, March 8, 12
Thursday, March 8, 12
Thursday, March 8, 12
Thursday, March 8, 12
Thursday, March 8, 12
Thursday, March 8, 12
Thursday, March 8, 12
Thursday, March 8, 12
Thursday, March 8, 12
Thursday, March 8, 12
Relationships Between BOUNDED CONTEXTS                        Shared KernelThursday, March 8, 12
Gzs%ef.     .  . . . . .   ,   .       .       .   .   .               .           .   .   .   .           .       .      ...
Programming                       R. Morris              Techniques                        Editor                         ...
Programming                    R. Morris              Techniques                     Editor                               ...
Programming                    R. Morris              Techniques                     Editor                               ...
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
(v2.0) Better Functional Design Through Test-Driven Development
Upcoming SlideShare
Loading in...5
×

(v2.0) Better Functional Design Through Test-Driven Development

1,996
-1

Published on

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.

Published in: Technology, Business
2 Comments
7 Likes
Statistics
Notes
No Downloads
Views
Total Views
1,996
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
34
Comments
2
Likes
7
Embeds 0
No embeds

No notes for slide

(v2.0) Better Functional Design Through Test-Driven Development

  1. 1. Better Functional Design Through Test-Driven Development Phil Calçado - SoundCloud @pcalcado http://philcalcado.comThursday, March 8, 12
  2. 2. ohai! i’m phil.Thursday, March 8, 12
  3. 3. i work here:Thursday, March 8, 12
  4. 4. Thursday, March 8, 12
  5. 5. and so should you.Thursday, March 8, 12
  6. 6. http://bit.ly/work-at-soundcloudThursday, March 8, 12
  7. 7. Better Functional Design Through Test-Driven Development Phil Calçado - SoundCloud @pcalcado http://philcalcado.comThursday, March 8, 12
  8. 8. better? what’s good functional design, to begin with? Better Functional Design Through Test-Driven Development Phil Calçado - SoundCloud @pcalcado http://philcalcado.comThursday, March 8, 12
  9. 9. I have no idea.Thursday, March 8, 12
  10. 10. how I got started with objectsThursday, March 8, 12
  11. 11. Thursday, March 8, 12
  12. 12. Thursday, March 8, 12
  13. 13. Thursday, March 8, 12
  14. 14. Thursday, March 8, 12
  15. 15. Thursday, March 8, 12
  16. 16. Thursday, March 8, 12
  17. 17. Thursday, March 8, 12
  18. 18. Thursday, March 8, 12
  19. 19. Thursday, March 8, 12
  20. 20. Thursday, March 8, 12
  21. 21. Relationships Between BOUNDED CONTEXTS Shared KernelThursday, March 8, 12
  22. 22. Gzs%ef. . . . . . . , . . . . . . . . . . . . . . . . . . . . . . , . . . . . . . . . . . . . . . . . . . . . . . . . . . .Permission to copy without fee all or part of this materinl isgranted prowded that the topics are not mada or distributed fordirect commcrciol advantage, the ACM copyright notice ond tholillc of the publication and its dare appear. and notice is giventhat copying is by permission of the Association for ComputingMachinery. To copy othcrwisc, or to republish. requires B feeand/or specific pornlission.HOPL-11/4/93/MA,USAo 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. 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. Authors 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 12Thursday, March 8, 12
  24. 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 Authors 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. 1Thursday, March 8, 12
  25. 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 Authors 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. 1Thursday, March 8, 12
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×