Static Typing Gives You a Head Start, Tests Help You Finish
Join the DZone community and get the full member experience.
Join For FreeIn one of my earlier posts (almost a year back) I had indicated how type driven modeling leads to succinct domain structures that inherit the following goodness :
- Lesser amount of code to write, since the static types encapsulate lots of business constraints
- Lesser amount of tests to write, since the compiler writes them implicitly for you
In a recent thread on Twitter, I had mentioned about a comment that Manuel Chakravarty made in one of the blog posts of Micheal Feathers ..
"Of
course, strong type checking cannot replace a rigorous testing
discipline, but it makes you more confident to take bigger steps."
The statement resonated my own feelings on static typing that I have been practising for quite some time now using Scala. Since the twitter thread became louder, Patrick Logan made an interesting comment in my blog on this very subject ..
This is interesting... it is a long way toward the kind of explanation I have been looking for re: "type-driven programming" with rich type systems as opposed to "test-driven programming" with dynamic languages.
I am still a big fan of the latter and do not fully comprehend the former.
I'd be interested in your "type development" process - without "tests" of some kind, the type system may validate the "type soundness" of your types, but how do you know they are the types you actually *want* to have proven sound?
and the conversation became
somewhat longer where both of us were trying to look into the practices
and subtleties that domain modeling with type constraints imply on the
programmer. One of the points that Patrick raised was regarding the
kind of tests that you would typically provide for a code like this.
Let me try to look into some of the real life coding that I have been using this practice on. When I have a code snippet like this ..
/**
* A trade needs to have a Trading Account
*/
trait Trade {
type T
val account: T
def valueOf: Unit
}
/**
* An equity trade needs to have a Stock as the instrument
*/
trait EquityTrade extends Trade {
override def valueOf {
//.. calculate value
}
}
/**
* A fixed income trade needs to have a FixedIncome type of instrument
*/
trait FixedIncomeTrade extends Trade {
override def valueOf {
//.. calculate value
}
}
//..
//..
/**
* Accrued Interest is computed only for fixed income trades
*/
trait AccruedInterestCalculatorComponent {
type T
val acc: AccruedInterestCalculator
trait AccruedInterestCalculator {
def calculate(trade: T)
}
}
I need to do validations and write up unit and functional tests to check ..
- EquityTrade needs to work only on equity class of instruments
- FixedIncomeTrade needs to work on fixed incomes only and not on any other instruments
- For every method in the domain model that takes an instrument or trade, I need to check if the passed in instrument or trade is of the proper type and as well write unit tests that check the same. AccruedInterestCalculator takes a trade as an argument, which needs to be of type FixedIncomeTrade, since accrued interest is only meaningful for bond trades only. The method AccruedInterestCalculator#calculate() needs to do an explicit check for the trade type which makes me write unit tests as well for valid as well as invalid use cases.
trait Trade {The moment we add these type constraints our domain model becomes more expressive and implicitly constrained with a lot of business rules .. as for example ..
type T <: Trading
val account: T
//..as above
}
trait EquityTrade extends Trade {
type S <: Stock
val equity: S
//.. as above
}
trait FixedIncomeTrade extends Trade {
type FI <: FixedIncome
val fi: FI
//.. as above
}
//..
- A Trade takes place on a Trading account only
- An EquityTrade only deals with Stocks, while a FixedIncomeTrade deals exclusively with FixedIncome type of instruments
Consider
this more expressive example that slaps the domain constraints right in
front of you without them being buried within procedural code logic in
the form of runtime checks. Note that in the following example, all the
types and vals that were left abstract earlier are being instantiated
while defining the concrete component. And you can only instantiate
honoring the domain rules that you have defined earlier. How useful is
that as a succinct way to write concise domain logic without having to
write any unit test ?
object FixedIncomeTradeComponentRegistry extends TradingServiceComponentImpl
with AccruedInterestCalculatorComponentImpl
with TaxRuleComponentImpl {
type T = FixedIncomeTrade
val tax = new TaxRuleServiceImpl
val trd = new TradingServiceImpl
val acc = new AccruedInterestCalculatorImpl
}
Every wiring that you do above is statically checked for consistency - hence the FixedIncome component that you build will honor all the domain rules that you have stitched into it through explicit type constraints.
The
good part is that these business rules will be enforced by the compiler
itself, without me having to write any additional explicit check in the
code base. And the compiler is also the testing tool - you will not be
able to instantiate a FixedIncomeTrade with an instrument that is not a subtype of FixedIncome.
Then how do we test such type constrained domain abstractions ?
Rule #1:
Type constraints are tested by the compiler. You cannot instantiate an
inconsistent component that violates the constraints that you have
incorporated in your domain abstractions.
Rule #2: You
need to write tests for the business logic only that form the
procedural part of your abstractions. Obviously! Types cannot be of
much help there. But if you are using a statically typed language, get
the maximum out of the abstractions that the type system offers. There
are situations when you will discover repetitive procedural business
logic with minor variations sprinkled across the code base. If you are
working with a statically typed language, model them up into a type
family. Your tests for that logic will be localized *only* within the
type itself. This is true for dynamically typed languages as well.
Where static typing gets the advantage is that all usages will be statically checked
by the compiler. In a statically typed language, you think and model in
"types". In a dynamically typed languages you think in terms of the
messages that the abstrcation needs to handle.
Rule #3:
But you need to create instances of your abstractions within the tests.
How do you do that ? Very soon you will notice that the bulk of your
tests are being polluted by complicated instantiations using concrete
val or type injection. What I do usually is to use the generators that ScalaCheck offers. ScalaCheck offers a special generator, org.scalacheck.Arbitrary.arbitrary,
which generates arbitrary values of any supported type. And once you
have the generators in place, you can use them to write properties that
do the necessary testing of the rest of your domain logic.
Opinions expressed by DZone contributors are their own.
Comments