Partial Mocking and Scala

I don’t know how to get this across with the level of excitement it brought to me as I discovered it.  But I’ll try.

I love TDD – the clarity, focus, and downright beauty it brings to software creation is absolutely one of my favorite parts of doing it.  I love the learning that it drives, and I love the foundation it lays for a masterpiece of simplicity.  It’s unparalleled as a programming technique — I only wish I would have caught on sooner.

I love Scala.  I can’t seem to find the link – but there was a good list about how to shoot yourself in the foot in various languages – in Scala, you stare at your foot for two days and then shoot with a single line of code.  The language is amazing in its ability to let you get across your meaning in a radically concise, but type-safe way.  I often find myself expressing a thorough bit of business logic in one or two lines.  Things that would have taken 20-30 lines in a typical C-derivative language.  It’s a fantastic language.

Writing Scala – I’ve gotten into a situation that finally, powerfully, crystallized in an experience this morning.  I spent probably an hour struggling to get at the most understandable, most flexible solution.

The situation is this – I have a class that’s definitely a reasonable size – 30-50 lines or so.  In this case, most of the methods were one-liners.  And they were one-liners that built on each other.  The class had one Responsibility, one “axis of change”.  I liked it as it was.

One problem that arose was that one of the methods was wrapping some “legacy code” (read: untestable – and worse unmockable).  In my Java days – this wouldn’t have even arisen as a problem, because the method using the legacy code would have probably warranted its own class, and thus I could have easily just mocked that class.  As it was, I considered it.  But as I said, the class was very expressive, and said as much as it should have, without saying any more.  To cut a one line method and make it a one line class…would have bordered on ridiculous – it would have been far too fine grained at any rate.

So what’s a code-monkey to do?  Well – I tripped across this idea of a partial mock.  Which, I would have derided as pointless in my Java days – and in fact, the prevailing wisdom on the interwebs – was that partial mocking is bad.  I don’t want to do bad.  By the way, if you haven’t googled it already – partial mocking is simply taking a class, mocking out some methods, but letting others do their original behavior (including calling the now mocked methods on the same class).

Anyway – the more I stared at the problem and balanced the two forces at play, the more I realized how right the solution really is.  In my experience, in Scala, the scenario I just laid out is common, and the only real way to solve for it is with partial mocking.

(Big thanks to Mockito for providing this capability – so awesome!)

Why Patterns Suck


, , ,

I was at a jazz jam session a few years back. I didn’t know it then – but I was learning a valuable lesson about design patterns.

Music, in its similarity to software, has a class of design patterns called scales (think Sound of Music – “doe re mi fa so..”).  Scales help musicians to have an intuitive understanding of the harmonic relationships between different pitches.  These relationships have mathematical connections that lead to a lot of simplification and a lot of carrying lessons learned in one context to another context.  There is a lot of value in deeply thinking about these relationships, and getting them “under your fingers” – getting an intuitive feeling for them by playing them.

The jazz solo is an interesting thing – it’s a time for a musician to attempt to convey feeling to the listeners, following as few rules as possible.  Though there are a lot of underlying laws to how to create certain feels….most musicians, in order to be able to express feeling in real-time, work hard to have an intuitive grasp of these laws.  Thinking through the specific details of the performance while performing would be impractical, and it would destroy the original inspiration.  Hence, musicians have located patterns (such as scales) – that allow them to work on that grasp when not performing.

After stepping down from my solo (which was undoubtedly life-changing for the audience) … another soloist took the stage.  He played scales.  For the whole solo.

A fellow listener leaned over and whispered in my ear about the ineffectiveness of the approach….in more colorful language.

Scales… design patterns in any domain are for developing intuitive understanding of the space.  They are NOT to be included for their own sake, thoughtlessly in the actual creation.

I’ve seen this a couple of times, at grand-scale, in software.  In the early 2000’s – I can’t remember how many singletons I saw cropping up all over the place (yeah, I may have been responsible for a few of those)…many, many times very unnecessarily.

These days there are a number of patterns that get picked up and used wholesale (with little thought) – MVC, Monad, Lambda, Onion, etc..  This is not how great software is written.  Like music – the domain has to be well-understood, and then the thing created from that understanding.  Picking up the design patterns, whether they’re scales or singletons, and instead of using them in private to gain understanding, we pass them off as creation, we are using them in exactly the most wrong (and harmful) way.

It will make our software worse – decreasing our understanding, and increasing the complexity of our software by creating code that doesn’t match the problem.





“I would sooner destroy a stained glass window than an artist like yourself. However, since I can’t have you follow me either…”The Dread Pirate Roberts (shh – actually it’s Wesley)

Wesley proceeds to bonk Inigo over the head (saber-whips him?) rather than killing him. It’s fortunate for Inigo that Wesley had such an appreciation for his art and the calibre of craftsman that he was fighting against. A lesser man may have gone ahead and destroyed the stained glass window.

In software – it’s not (at least in my experience) so dramatic – we don’t find ourselves in life or death situations based on the level of our craft. But an understanding and recognition of the level of our craft is an important and powerful thing. It’s almost like oxygen to our sense of contentedness with the world, to our self-worth, to the level of fun we’re having crafting software.

This is important for two reasons. Reason number one is that – the craftspeople that we work with share this need – and as we grow and progress in the craft, we are able to provide it for more and more people. The embedded thing here though is that we are only able to provide this oxygen to people whose level of craft we understand and can truly appreciate – folks that are at or below our level. And we should take every opportunity to do this – because it’s good to do this for our fellow human, and because it increases by untold amounts the effectiveness of those around us.

The second reason is because many times we will find ourselves going without oxygen. We need to recognize this – because if we are not careful, it can have massive negative effects on every part of our being – even including our physical health.

What can we do about this..

First – be aware that it is a thing. And be ready to remedy it when it happens. Second – know what some of the remedies are.

They include…

1) Holding your breath – we can for a time go without oxygen without permanent effects – know your limits, but be prepared to hold your breath.

2) Surrounding yourself with craftspeople that are at or ahead of your level. They are the only ones that will recognize your craft – and thus the only ones that can provide the much needed oxygen. This is a hard one though – it may mean leaving comfort for an ultimately better situation in a number of different ways; choosing a different team, engaging people that you don’t have a natural affinity for, or leaving an organization.

The Case for Scala

Why take sides if you don’t have to?  It’s uncomfortable; people get upset with you for not seeing things their way; you find yourself spending a lot of time thinking on and defending your position.  Thinking is hard, am I right?!

In technology, things change so much – new tools rise and fall – new techniques rapidly give way to newer techniques.  And large swaths of tech are based on the particular preferences or biases of their creators and/or the community that uses them.  Many times choosing one tool over another is only a matter of taste. Don’t get me wrong – informed taste is the underpinning

hammerof great software.  A set of tools, though, all sharing the same basic properties but offering different ways of going about them – sharing substance, differing in style – make the idea of picking tech less like “picking the right tool for the job” and more like “do you want a red handle on your hammer or a pink one with sparkles?”.

It is INSANE to expend significant energy on the handle of your hammer.  Pick what you like and use it – don’t try to convince anyone to come along and ignore anyone who says red is better than pink.

There are, though, tools that are demonstrably better.

Scala is one of these.

Being a better tool depends on what kind of job you are trying to accomplish.

If you are a software craftsman – focused on creating software that is elegant, just because you can…..if you know that clean, clear code leads to better software in the hands of your users…..if you respect the next developer to look at the codebase enough to leave them a work of art rather than a work of excrement…..then Scala is one of the most premium tools available today.


There are several reasons – they are fairly subtle – but they add up to granting a deeper ability to craft great software to the person interested in doing such a thing.

#1 – It has a type-system.  Type-systems are like free unit tests.  Unit tests are good.

#2 – It leverages both the object metaphor and the functional/mathematical metaphor – giving you a great degree of expression.  It subtly encourages good stateless, immutable, referentially transparent structuring of your code, but gives you the flexibility to not be that way if you judge the situation to warrant it.

#3 – It (while having great static typing) offers an extremely malleable language, with plenty of syntactic sugar to help you get your point across in the most concise way possible.

scala-hammer All of these come down to the fact that the language is more expressive than anything else available.  And all of this while running on the JVM – providing a battle-tested runtime environment and a time-tested community of brilliant developers that consistently create the most advanced eco-system around.

Choose Scala
.  You will write better software.


Increase your Code Covfefe with these three easy steps…

Test First

Plenty has been said on this particular topic.  But I constantly have conversations with folks that aren’t quite convinced of the value that this brings, especially with regards to code covfefe.  There are only two things I can do to convince you on this – and one of them is entirely in your hands.

The first is to make the argument.  Of all the solutions to a particular problem, the crisply-defined, highly-modular ones that makes testing easy are only a small subset of the larger solution space.  If you feel your way around intuitively to the solution as many of us do, the statistical likelihood that you will trip on this subset is small.  Most of the time, you will find yourself doing significant refactoring in order to accommodate tests after the fact.  This is lame, and feels like an utter waste of time – which makes it less likely that we will continue to do it.

The second thing that I can do is just to urge you to try it – earnestly try it.  You will love it.

To increase your code covfefe – drive your development with testing.

Write Modular Code

We used to think that modularity was all about reuse – but two weeks into a software engineering career you realize how ridiculous the promise of reuse really is (at least in the uplanned way suggested by our CompSci professors).  But modularity is still super important.  Modularity means flexibility, flexibility means three things: speed, expressiveness and testability.  You want your systems to grow and come to life faster – write modularly.  You want the person that follows you in a code base to love you instead of hate you – write modularly.   You want high levels of code covfefe – write modularly.

Why does modular code lead to more covfefe?  Because it’s easier, many times WAY easier to test.  Every level of nested anything multiplies the complexity of the test code that’s covering (covfefing? not quite sure about the conjugation) it – whether that’s nested conditionals or loops.  That is, the complexity of a test is almost exponentially related to the complexity of the production code it’s testing (this is totally not any kind of scientific analysis – it’s based only on years of doing this myself).  When a module (class, method, function, whatever) violates good modularity principles, the tests get hard to write.  And thus, again, hard to write tests means less covfefe.

As a side note – this can play to your advantage – because, aside from understanding good design principles (like SOLID), a good way to keep your code modular is to “listen to the tests”.  If the tests get difficult to write, your code is probably getting a little monolithic.

To increase your code covfefe – write modular code.

Make Human Space

It behooves all of us to understand well the iron-triangle – features, time, and quality.  You can lock in any two of these at a time.  One of the most oppressive, evil, and seemingly unintentional things that happens in corporate software development settings is that extreme pressure is placed on features and time being locked in.  The iron triangle is a law of the universe.  Putting intense pressure to lock in two of the arms necessarily leads to compromising the third.  Which plays out in terms of overwork, less test covfefe, sloppier coding, etc.

Fortunately we have some nascent tools in our tool chest to deal with this situation (viz. agile, scrum, etc).  The wise engineer will apply these techniques to make the space to apply their craft in a professional manner – with high quality, and much test covfefe.  The challenge though is that some of the impediments to really embedding agile approaches in an organization can not be entirely “bottom up”.

To increase your code covfefe – make the space for your team to focus on quality, using agile, scrum and any other methodological tool you can find.


When is an MVP not an MVP?

All life is an experiment. The more experiments you make the better.Ralph Waldo Emerson

Jim Collins is great for boiling deep truths that he’s come across with a great deal of study and research into memorable ideas.  One of my favorites is the “Fire Bullets then Cannonballs” idea.

The gist is – you make small investments (a lot of them), trying to find something that works, and then, once you’ve proved to yourself that you’ve found something, then you invest big.

There’s an underlying assumption in that, that you have any kind of an idea up-front how much your particular brand of ammunition will cost.  In software, this as we know, is false…always.

Collins’ tip of the hat to the unknown for the (ubiquitously lusted after) product-market fit is right on.  But, in software at least, the unknowns go a bit deeper.  Bullets can become cannonballs in the process of firing them. 🙂

The idea holds true though – one piece of wisdom needs to be layered on here though.  And it’s pretty straightforward.

As we are firing our bullets – we need to decide ahead of time how much a bullet costs.  And when it crosses that threshold we need to make a conscious choice to either continue firing (knowing that it has become a cannonball) or to consider ourselves to have fired a failed bullet and move on.

The options here are pretty obvious – the important bit is that we are making decisions intentionally, and not letting ourselves slide into the path of least resistance (which as we know, makes for crooked rivers and crooked men…..and I would argue, crooked organizations).

As for practical take-aways – it is of the utmost importance to make this decision as quickly as possible.  If we have month-long delivery cycles – we may find our bullet has become a cannonball early leaving us with a large bit of time wasted that we could have spent on more bullets.  Sprint cycles should be as small as you can possibly get away with – as should production release cycles.  And more importantly, both inside the business and out – we should structure the organization that there is plenty of review, so we know both the size and value of the bullets that we fire.


The ONE Lie Your Computer Science Professor Wouldn’t Stop Telling You.


, , ,

What is this lie?  It’s not subtle – and in fact like any great deception – it has been doubled-down on over and over again.  So much so, that it’s actually carried around as if it were the DEFINITION of truth – the one true way to design software. And like many of the most successful lies throughout history – it seems viable, even helpful in the short term but carries with it long-term, bad consequences.

What if I told you – everything you’ve been told about OOP is a lie.

The lie goes something like this “The purpose of an object is to encapsulate data behind behavior”.  The idea is that we expose the things we want to do, and then implicitly have some backing information with which we accomplish those things.

As with any good lie – it starts with a kernel of truth – viz. yes, exposing only one thing is important, so you shouldn’t expose data if you are going to expose behavior.  The lie begins with the idea, that the object, a single object, embodies both.

At a bare minimum, this will always represent a violation of SRP.  No matter how closely related, specific behavior and any data that are related to that behavior represent two reasons to change, and thus two “Responsibilities” in the SRP sense.

So to say this again generally, the old wisdom about the purpose of Objects being to hide data behind behavior, especially its implication that this means the same object does both, is a violation of SRP, and is actually more like an OO anti-pattern.

Why should you care?

For all the reasons you’d care about following SOLID principles in the first place.  Violating them means that your code will be less adaptable, and communicate its intent less clearly.  I’ve personally seen plenty of code that blindly follows this common wisdom – and it bares out the fact that adhering to this lie does us no favors.

But Morpheus’ approach to sharing deep truths like this is very applicable – as with SOLID generally, or TDD, or Agile Principles – one cannot really be told about the matrix – one must see it first hand.  So – I would challenge you – find some code that follows the one-object-hides-data-with-behavior anti-pattern.  Imagine modeling it, or even try modeling it in a way that separates out the responsibilities, and see if you don’t end up with clearer, cleaner, more flexible code.


Constitutional Agility

Twelve score and one year ago as our nation was born – a huge shift in thinking moved its way into practice with regards to how we structure ourselves as people and ultimately as nation-states.  This was, of course, the culmination of the thinking and experimentation that had taken place prior to this big occasion.  But none-the-less, it marked an important milestone as we put into practice the theory that had been slowly cooking over the preceding years.

The ultimate goal was the good of mankind – the freedom to think, act, and be who the Creator made us to be – which, as it turns out, is also highly productive way to be – and has led to much prosperity.

We have zeroed-in on a (reasonably) decent system of organizing ourselves at the macro level – government that balances the passions and energies of a massive society, while maintaining order and freedom.  There’s a fractal nature to this though – and as we’ve worked our way down into the smaller scales in the organizations that we work for  – we find that the same impulses that have led to despotic oppression and systematic mistreatment of people are still very much alive and well.  More importantly they remain unbalanced by thoughtfully laid-out systems that direct and harness our in-built not-so-perfect nature.

I have worked at a number of different organizations, of different sizes, industries, cultures and levels of distribution.  And I’ve found that with regards to delivering software – the problems and challenges are very much the same regardless of any of these variables.  And further, the challenges boil down to the EXACT same thing that the founders of the United States grappled with as they attempted to create a sustainable government.

The challenge and tension is this – we know a few things – we know that people should be given as much freedom to act as possible and as much context as is available to handle their affairs.  Our short-term human passions sometimes override our reason and our understanding about these things that we know.  That is, in the short-term, I can be convinced by how I am feeling emotionally that I should hold back context, and dictate specific actions.

I’ve seen the results of this personally.  I’ve seen something which I am betting, because it is based on the same fundamental realities, is an echo of the past.  I’ve seen organizations oscillate between liberty and despotism – to use the modern lingo, between “agility” and “waterfall”.  And it’s very much because of this singular reason – we know the right things we ought to do (providing liberty and context) – but we don’t do them because the passion of the moment can override our reason.

I propose that we begin to rethink how a modern knowledge-work-based organization should be structured.   I always say that good artists borrow and great artists steal.  I propose that we brazenly steal the methodologies and tactics that the founding fathers applied at the macro level and apply it in the micro.

For example, it should be difficult and consensus-building to change certain fundamental parts of working method.  One of the most fundamental parts of achieving liberty/agility in software is to ensure that teams are broken down by functionality or value actually provided to the customer, rather than by technology capability (e.g. api, front-end, etc).  WHAT IF…and hear me out, here, because this might sound crazy….WHAT IF – in order to move away from that (or to make any change) meant either gaining a 2/3 majority of all employees OR paying bonuses of half the net-worth of the company.

This would COMPLETELY remove the idea that “hey, short-circuiting things here is really a means to more money for the company” (a short-term passion overriding the bigger picture good).  And if it was REALLY important, it’d still be possible – but force either real serious consensus building…or a bunch of cash paid out to the employees.  Both of which would tend toward buy-in (or at a minimum anesthetization) for any short term pain.

So – perhaps we write a constitution about these things.  Perhaps we appoint people (that can’t be un-appointed on a whim) to interpret if something really is a violation of that constitution.  Perhaps we have a body of employees that are co-equal with executive managers – that can tweak the specifics of the rules.

I don’t know what all the details might look like – this idea only struck me this morning.  We’ve never thought this way in the past – but reality is shifting – more and more the expertise and intelligence about the operation of the business is in the hands of the leaf-nodes in the organizational graph – and so the old approach might be ripe for change.  This shift, coincidentally, is very similar to the shift of expertise and inherent productivity that was taking place just prior to and during the founding of the United States.

Anyway – thanks for listening – in the comments, please share thoughts, rebuttals, or any snide remarks.


Agile Is…

Agile is a moral imperative.

It is a measuring stick – a tool that lets you ask the question of yourself – how well am I treating those I work with?  How well am I leveraging my gifts and the gifts of the people around me for the benefit of the organization and the population that it serves.

Agile is not the path of least resistance. 

After a while in the software industry I developed what I think is a pretty common assumption – that we are slowly becoming more enlightened, and that the following generations won’t even remember what it was like to do software in a top-down, serialized, homogenized way (e.g. using the evil and ubiquitously feared “waterfall” method).  I’ve discovered over the last several years – that every generation rediscovers and reignites their passion for controlling, attempting to eliminate unpredictability and (intentionally or unintentionally) manipulating others for their own benefit.  Every generation reinvents Waterfall.

This is because it’s intuitively right on the surface – and because it takes deep curiosity, and tremendous amounts of earnest energy to get past that intuitive crust to the meaty, counterintuitive center of the issue.  Breaking past waterfall requires special people – especially invested in each other, longing to build something great.

Agile does NOT scale.

Again – a totally intuitive thing to look for, Scaled Agile simply doesn’t exist.  In our eagerness to produce as much as possible as fast as possible (I’m being generous here – the real blinding factor might more likely be a deep, abiding greed – looking to make as much money in the shortest amount of time), we want to scale our business rapidly, and by extension anything that makes our business run.

Scaling is the art of throwing more raw resources at a thing and getting more finished product.  People being the raw resource of Agile – you cannot simply throw more people at a software shop and get more agile.

The real question is – “How do we scale our business while continuing to have Agile characteristics (empowerment, full context, rapidly adapting to change, and generally treating people well)?”  The answer is to structure your organization such that all decisions are pushed to the lowest possible level and that context is not removed for the sake of short-term goals.

Agile is hard work.

The answer to the implied question “then what do we do?” – is that we think.  We choose not to do something because of its level of required effort.  We decide that we want to treat people well, add value to the greatest extent possible, and build a great organization.  Then we do the hard work to think through the myriad of counter-intuitive but high-leverage problems that make the rediscovery of Waterfall such an inevitability in a world with no shortage of people looking for the easy way.


Unit Testing, Scala and Functional Programming

The questionWhat place does unit testing have in the functional or hybrid world?

This is kind of a tough post for me to write – since the whole point is that I’m still a little fuzzy about how the idea of unit testing connects with the new (to me) world of functional and hybrid-functional programming languages.

I am not entirely sure how generalize-able the things are that I am discovering.  I come from a straightforward background of enterprise and web-scale software development.  I’ve done it mostly with Java and its ecosystem, with a quick walk through the C# and .NET world a few years back.

Throughout the course of my career – I’ve come to settle on a several things that I deeply believe in.  Two of which are pertinent here – that there are a collection of principles that are common to all software development regardless of the particular technology (currently, most precisely spelled out as the SOLID principles) and that unit testing, because of the impact it has on our thought process, results in better, more modular software.

I started slipping down the functional programming rabbit hole without realizing it several years ago.  I went on an interview – and the folks interviewing me were asking me about my exposure to Scala.  I hadn’t even heard there was a Scala 🙂  The job didn’t end out working out – but after googling Scala, I slowly fell in love with it.  I’m still not any kind of functional programming master – but the ability to think in terms of classes and objects, while beginning to leverage higher-order functions and all the goodness that functional programming brings to the table was and is incredibly inspiring.

Scala has been called a tasteful hybrid.  I like that.  Incidentally, As I’ve continued to stumble down the rabbit hole, I’ve started to become really excited by Haskell.

At any rate, I’ve also come to believe that there is a Great Convergence happening.  A convergence between Object Oriented thinking and Functional thinking.  We tend to think of these things as mutually exclusive – but I would suggest that not only are they NOT mutually exclusive – the thinking about both are zeroing in on the same thing.  They’re zeroing in on a set of underlying principles about how to write well-structured software that speaks to the human reading it as well as it does to the machine that is executing it.

The SOLID principles that I mention above are perhaps not a perfect representation of the actual underlying principles – but they are definitely the best and closest articulation currently available.

Just to address one problem that I believe obscures our vision here – when we think of FP being at odds with OO, I would suggest that we’re actually thinking of the Imperative style that a lot of OO practitioners leverage as a matter of habit.  But OO programming does not imply Imperative programming, which is the thing that is *actually* at odds with FP, and not necessarily converging on the same set of principles.

As an example – one thing that people think of as a commonly accepted OO practice, but that actually violates SOLID principles, is the idea of having a class that encapsulates BOTH data and behavior.  This is ALWAYS, necessarily a violation of SRP.  But when folks make the argument that OO is going a different direction than FP, they often cite examples of this.  Those that are seeking to understand and apply the underlying principles that lead to code that speaks to the reader and not only the machine, are not writing classes like this – they are writing OO code that is converging more and more into the space that FP is at or is heading to (I have to be careful here – I’m still a bit of a FP neophyte – so I want to be careful about speaking too strongly for any portion of the FP community).

So stepping back…

The questionWhat place does unit testing have in the functional or hybrid world?

So I’ve tried several approaches and thumbed through a number of GitHub repositories to try to gauge where things are at. And I have yet to come across anything particularly definitive.

Taking a couple more steps back – throughout my career in the mainstream OO world (again, primarily Java with a short stint in C#), I have observed that Unit Testing, for whatever reason, leads developers to write more modular code that more closely follows good underlying software principles (e.g. SOLID).  And because of this, the code is easier to understand and to think about.  I do not believe this needs scientific rigor or detailed data to prove – for me, it’s a matter of honestly assessing even a small degree of practical experience.

I can see no reason why the move from classes as the carrier of meaning to first-class functions as the carrier of meaning would change this effect at all.

So this being the case, as I dug into Scala, I began to try several approaches to bringing Unit Testing to bear…

As we’ve said a couple of times here – Unit Testing applies pressure toward more closely meeting those underlying software development principles.  One of the principles that gets a lot of play, since it has historically required sophisticated frameworks to meet in the Java world, is the Single Responsibility Principle with regards to dependencies.  That is, in order to isolate the choice and creation of dependencies, purpose-specific frameworks like Spring or Google Guice were needed.

So my first step was to pursue that isolation directly.  I tried Guice, then I tried the cake pattern, then I customized the cake pattern to be as minimal as possible, then I tried implicitly passing around dependencies as needed…getting more and more minimal as I discovered the implications of the FP constructs available in Scala.

And then at some point I even started asking myself why I even needed a class – if I’m really following SRP, a class seems to ALWAYS be too much….though, it provides a good organizing structure, much like a package.

My production code seemed to proceed in the same direction – getting smaller and smaller.  More meaning expressed in fewer keystrokes.

It didn’t click with me at first – but this has a massive impact on the meaning of unit testing.  Ten lines of for-loop code, with variables to track the iteration, logic to perform the iteration, boundary checks and of course actual business logic can be boiled down to a single line of code with functional constructs.  A single line of code that only consists of the new meaning that you’re looking to express.  This is a big deal.

My Java unit testing practice – was to always have a method doing one atomic thing – and to unit test every method.  In the Scala world – this tips the balance, even for a practiced unit tester, toward too much investment for the return on structural clarity.

The questionWhat place does unit testing have in the functional or hybrid world?

So my conclusion here is two-fold:

  1. We don’t really know yet – but we’re working on it.
  2. As with everything in FP, it’s a FAR more fluid, artful, subjective and personal thing than it was in the more structured world of the last generation of languages.

Also – I’d like to highlight, if the tone hasn’t come through in this post, that this is something of a cry for help.  If you have any additional insight on this – please email.  I’m very interested to see where this starts to land.  Or, if it already has landed and I’m just not aware of it – that would be great to know as well.