"Play fast and loose with faith? So jest with heaven,
Make such unconstant children of ourselves"
-- Shakespeare, King John
Act III, Scene I, Lines 242-243
For C# development, I love to use AutoFac! I find that AutoFac allows me to change the design of my code without having to worry about decencies. The last thing I want to have to do while refactoring my design is fix a bunch of broken unit tests. Typically if find that I have to support hard coded test setup for the system under test, when I change the signature of the constructor I'll also need to change all the test setups related to the class (this is often the case in code in which I was not the original author). This can become very annoying, since the test cases often do not really care about the setup of the system under test.
If you are using a decency injection framework like AutoFac you really need to pair the loose coupling of your production code decencies with loose coupling of the setup of your system under test. Loose coupling of the setup of your system under test is exactly what a test fixture is for.
Personally I love AutoFixture for C# development! AutoFixture does all the hard work of creating a test fixture for you, all you have to do is walk up to it and ask it for what you want.
If you are using AutoFac or some other IoC framework in your system under test, more likely than not, you are using a mocking framework like Moq or Rhino Mocks. Well, AutoFixture has you covered by allowing you to use an auto mocking plugin for Moq, Rhino Mocks, or whatever. By using auto mocking along with AutoFixture you are able to create a system under test with all the decencies already mocked out.
With AutoFixture creating the system under test for you, you can freely change the signature of your constructor for your system under test without the need to change any of the setup for the test cases!
Say we have the following:
The above is a fairly common example of C# application that I work with.
We see that we are testing using two different test classes, one using AutoFixture and one not. If we uncomment out the ILog decency in the System class we would break the test setup in the test class ProgramTestsWithoutAutoFixture, but the test class SystemTestsWithAutoFixture would continue to work! For such a simple example this might not matter, but with larger code bases this can become an issue.
By using AutoFixture with Moq we are pairing the same loosely coupling of the creation of our system under test with the loosely coupling we get for our decencies in our production code using AutoFac. Truly one can say, AutoFac iff AutoFixture with Moq.
Saturday, March 12, 2016
Sunday, February 21, 2016
Unquote, App.config, and You
"What curious eye doth quote deformities?"
-- Shakespeare, Romeo and Juliet
Act I, Scene IV, Line 31
I've started using Unquote for my assertions with F# xUnit tests. I find that its step-by-step failure messages really help in figuring out what is going on.
One thing that really throw me when I first used it was the System.MissingMethodException exception that Unquote was throwing at runtime. Luckily I was able to find this StackOverflow answer. It seems that you need to do a binding redirect for FSharp.Core, so you'll need to set up an App.config file in your test project like this example of the Coin Changer kata (using MapFold).
Happy coding.
-- Shakespeare, Romeo and Juliet
Act I, Scene IV, Line 31
I've started using Unquote for my assertions with F# xUnit tests. I find that its step-by-step failure messages really help in figuring out what is going on.
One thing that really throw me when I first used it was the System.MissingMethodException exception that Unquote was throwing at runtime. Luckily I was able to find this StackOverflow answer. It seems that you need to do a binding redirect for FSharp.Core, so you'll need to set up an App.config file in your test project like this example of the Coin Changer kata (using MapFold).
Happy coding.
Monday, February 15, 2016
Behold the Power of Mutation!
"And – ere a man hath power to say ‘ Behold!’ –"
-- Shakespeare, A Midsummer Night's Dream
Act I, Scene I, Line 147
One of the things I found very interesting in the Pluralsight class "Exploring C# 6 with Jon Skeet" was that the new interpolated strings works with expressions. Since C# is a mutable language we can easily abuse this!
In the above C# REPL we see that we can we can have all kinds of fun as long as we have an expression in our interpolated string.
Example:
var intValue = 0;
var stringValue = $"{((Func)(() => { intValue++; return intValue; }))() }"
As long as the expression has a ToString value it will work. Note, stringValue will only increment intValue once and after that it will always give the same result, but it is fun nonetheless.
Remember, never under estimate the power to abuse mutable languages!
-- Shakespeare, A Midsummer Night's Dream
Act I, Scene I, Line 147
One of the things I found very interesting in the Pluralsight class "Exploring C# 6 with Jon Skeet" was that the new interpolated strings works with expressions. Since C# is a mutable language we can easily abuse this!
In the above C# REPL we see that we can we can have all kinds of fun as long as we have an expression in our interpolated string.
Example:
var intValue = 0;
var stringValue = $"{((Func
As long as the expression has a ToString value it will work. Note, stringValue will only increment intValue once and after that it will always give the same result, but it is fun nonetheless.
Remember, never under estimate the power to abuse mutable languages!
Saturday, February 6, 2016
Item and Slice F#
"Slice, I say. Pauca, pauca. Slice! That's my humour."
-- Shakespeare, The Merry Wives of Windsor
Act I, Scene I, Line 125
I've been working my way through Dave Fancher's excellent Book of F# and found an interesting example of indexing and slicing arrays in F#. Since programming is a full contact sport, here is my take on indexing and slicing in F#.
We have a constructor for a type called Word which takes a string and separates it into words.
type Words(sentence : string)
We implement an index with the Item member.
member x.Item(i) = words.[i]
This allows us to access the words of the string given.
Words(sentence).[1]
We also implement an array slice with the GetSlice member.
member x.GetSlice(s : int option, e : int option)
This allows us to slice the array (substring it) of words in the string given.
Words(sentence).[1..2]
We can go one better than built in slice by allow for range in the slice to be bigger than the number of words.
let longer = 100
Words(sentence).[0..longer]
In order to allow for this we have to check to see if the end is greater than the number of words.
if e > words.Length then words.[s..] else words.[s..e]
and
if e > words.Length then words else words.[..e]
I hope I have shown that F# has some very nice support for objects.
-- Shakespeare, The Merry Wives of Windsor
Act I, Scene I, Line 125
I've been working my way through Dave Fancher's excellent Book of F# and found an interesting example of indexing and slicing arrays in F#. Since programming is a full contact sport, here is my take on indexing and slicing in F#.
We have a constructor for a type called Word which takes a string and separates it into words.
type Words(sentence : string)
We implement an index with the Item member.
member x.Item(i) = words.[i]
This allows us to access the words of the string given.
Words(sentence).[1]
We also implement an array slice with the GetSlice member.
member x.GetSlice(s : int option, e : int option)
This allows us to slice the array (substring it) of words in the string given.
Words(sentence).[1..2]
We can go one better than built in slice by allow for range in the slice to be bigger than the number of words.
let longer = 100
Words(sentence).[0..longer]
In order to allow for this we have to check to see if the end is greater than the number of words.
if e > words.Length then words.[s..] else words.[s..e]
and
if e > words.Length then words else words.[..e]
I hope I have shown that F# has some very nice support for objects.
Sunday, January 24, 2016
FizzBuzz and the Roman Numeral Kata are the Same Thing!
"The same, sir."
-- Shakespeare, Coriolanus
Act IV, Scene III, Line 7
As Homer Simpson pointed out, "Coke and Pepsi are the same thing!"
Similarly I plan to show that the FizzBuzz and Roman Numeral katas are the same thing!
Similarly I plan to show that the FizzBuzz and Roman Numeral katas are the same thing!
First let's look at the rules of FizzBuzz.
f(x : int) : string
if 3 | x and 5 | x then "FizzBuzz"
if 3 | x then "Fizz"
if 5 | x then "Buzz"
default string x
*note, 3 | x reads 3 divides x, in other words x / 3 does not have a remainder
In general we see that we have two (or three) rules and a default value, we are translating from the domain into the codomain following a set of rules, in other words we have a function.
if 3 | x then "Fizz"
if 5 | x then "Buzz"
default string x
*note, 3 | x reads 3 divides x, in other words x / 3 does not have a remainder
In general we see that we have two (or three) rules and a default value, we are translating from the domain into the codomain following a set of rules, in other words we have a function.
How about the Roman Numeral kata?
f(x : int) : string
fold
roman-numerals : (int, string)
lambda((x : int, m : string),
(k : int, v : string)) : (int, string)
while k | x then (x / k, concat m v)
(x, default string) : (int, string)
Again we see a list of rules for translation.
The only real difference to FizzBuzz is the fold across the rules, but we've hinted at this in the FizzBuzz description above. We stated that FizzBuzz has two (or three) rules, we can rewrite it using a fold with just the two rules using the fold to cover the "and" case.
We see the FizzBuzz and Roman Numeral as having the same shape which we use in the generalization in the "2 version". Thus using the same function with a set of rules, a defaulting function, and a seed we create both the FizzBuzz and Roman Numeral kata from the same general function!
Monday, January 18, 2016
MapFold OR Set Phasers to Fun
"Back to our brother of England."
-- Shakespeare, Henry V
Act II, Scene IV, Line 115.1
One of the things I love about functional programming is you can tell a lot about how a function works by just looking at its type signature. In F# 4.0 there is a new function to work with collections, here is it type signature:
('State -> 'T -> 'U * 'State) -> 'State -> C<'T> -> C<'U> * 'State
What do you think it does?
That's right this is a MapFold. Looking at its full definition we see the following:
let mapFold<'T,'State,'Result>
(f:'State -> 'T -> 'Result * 'State) acc list =
How does this work?
Looking at F#'s unit tests we see the following test name:
let ``mapFold works like map + fold`` () =
MapFold works like a map with a fold to maintain state. I know what you are thinking maintaining state is bad, that's why functional programming is easier to reason about. This is very true, but this is not a mutable state, this is an evolving state.
Let us look at an example, the Coin Changer kata:
The Coin Changer kata simulates one of those machines which give you back coins at a store. It takes a list of coin values and the amount of change to be given.
The Coin Changer kata is interesting since it has two things going on at the same time: 1) state and 2) list processing. In the Coin Changer kata you must maintain the amount of change you have left to give along with the amount of each coin to be given back. An example would be 99 cents with an US register, you would get back 3 quarters, 2 dimes, 0 nickels, and 4 pennies.
How would this example of 99 cents with an US register work with MapFold?
changeFor [25; 10; 5; 1] 99
We'll use s to hold the state, r to hold the result, and x to hold the current coin value we are looking at .
Processing the first value: x = 25, s = 99, r = [] resulting in s = 24, r = [3]
Second value: x = 10, s = 24, r = [3] resulting in s = 4, r = [3; 2]
Third: x = 5, s = 4, r = [3; 2] resulting in s = 4, r = [3; 2; 0]
Last: x = 1, s = 4, r = [3; 2; 0] resulting in s = 0, r = [3; 2; 0; 4]
There you have it, step-by-step through the Coin Changer kata using MapFold.
Guess what the source code to MapFold looks for the most part like what we just experienced. Here it is:
We see that it loops through each member of the collection, applying the function given against the state and current member. Once there are no more members it returns a tuple of the result along with the state. For the Coin Changer kata we do not care about the state (maybe we could use it verify that we have 0 cents) so we just drop it and get the result using fst.
There you have it the Coin Changer kata and MapFold seem to be made for each other.
-- Shakespeare, Henry V
Act II, Scene IV, Line 115.1
One of the things I love about functional programming is you can tell a lot about how a function works by just looking at its type signature. In F# 4.0 there is a new function to work with collections, here is it type signature:
('State -> 'T -> 'U * 'State) -> 'State -> C<'T> -> C<'U> * 'State
What do you think it does?
That's right this is a MapFold. Looking at its full definition we see the following:
let mapFold<'T,'State,'Result>
(f:'State -> 'T -> 'Result * 'State) acc list =
How does this work?
Looking at F#'s unit tests we see the following test name:
let ``mapFold works like map + fold`` () =
MapFold works like a map with a fold to maintain state. I know what you are thinking maintaining state is bad, that's why functional programming is easier to reason about. This is very true, but this is not a mutable state, this is an evolving state.
Let us look at an example, the Coin Changer kata:
The Coin Changer kata simulates one of those machines which give you back coins at a store. It takes a list of coin values and the amount of change to be given.
The Coin Changer kata is interesting since it has two things going on at the same time: 1) state and 2) list processing. In the Coin Changer kata you must maintain the amount of change you have left to give along with the amount of each coin to be given back. An example would be 99 cents with an US register, you would get back 3 quarters, 2 dimes, 0 nickels, and 4 pennies.
How would this example of 99 cents with an US register work with MapFold?
changeFor [25; 10; 5; 1] 99
We'll use s to hold the state, r to hold the result, and x to hold the current coin value we are looking at .
Processing the first value: x = 25, s = 99, r = [] resulting in s = 24, r = [3]
Second value: x = 10, s = 24, r = [3] resulting in s = 4, r = [3; 2]
Third: x = 5, s = 4, r = [3; 2] resulting in s = 4, r = [3; 2; 0]
Last: x = 1, s = 4, r = [3; 2; 0] resulting in s = 0, r = [3; 2; 0; 4]
There you have it, step-by-step through the Coin Changer kata using MapFold.
Guess what the source code to MapFold looks for the most part like what we just experienced. Here it is:
We see that it loops through each member of the collection, applying the function given against the state and current member. Once there are no more members it returns a tuple of the result along with the state. For the Coin Changer kata we do not care about the state (maybe we could use it verify that we have 0 cents) so we just drop it and get the result using fst.
There you have it the Coin Changer kata and MapFold seem to be made for each other.
Sunday, January 10, 2016
Data Structures Matters
"I see thee yet, in form as palpable"
-- Shakespeare, Macbeth
Act II, Scene I, Line 31
One of the katas we like to use at work while interviewing candidates is the Roman Numeral kata. It is a simple kata in which you create a function which takes an integer and gives you back a string representing the roman numeral representation of the number. It is fairly simple to explain but is deep enough to get a good idea of how the person works.
Here is a possible solution to the Roman Numeral kata in C#.
Looking at this solution we see a few things. The solution is using C# 6.0 syntax but beyond that we see three major things.
-- Shakespeare, Macbeth
Act II, Scene I, Line 31
One of the katas we like to use at work while interviewing candidates is the Roman Numeral kata. It is a simple kata in which you create a function which takes an integer and gives you back a string representing the roman numeral representation of the number. It is fairly simple to explain but is deep enough to get a good idea of how the person works.
Here is a possible solution to the Roman Numeral kata in C#.
Looking at this solution we see a few things. The solution is using C# 6.0 syntax but beyond that we see three major things.
- translation are being applied using the higher order function Fold (in C# Aggregate)
- mutation of the input value is used to maintain state through iterations
- translations are held in a Dictionary
Let us look at the Dictionary data structure which is the main focus of this post. In general a Dictionary is not ordered, now some implementations are ordered in the order in which the key value pairs are inserted (this is the case with the C# implementation), but this is not a property of the Dictionary data structure (see also the NIST entry).
Here is a possible solution to the Roman Numeral kata in Clojure.
Looking at this solution we see a few things.
We see that we cannot use a Dictionary (called maps in Clojure) to hold the translation. Clojure's HashMap uses Phil Bagwell's Hash Array Mapped Trie which makes no claim about order, in fact we see that maps (and sets) are unordered while vectors (lists and seq) are ordered. Since our algorithm requires that the translations be in the order we insert them we must use a data structure which preserves this order. Thus we must used something that is ordered like a vector.
How about F#? Here is a possible solution to the Roman Numeral kata in F#.
Looking at this solution we see a few things.
For the same reasons that we found in the Clojure solution we cannot use a Dictionary (called a Map in F#) since they are ordered by F#'s generic comparison and not in the ordered in which they were inserted. Luckily we can use a List which is ordered.
There you have it, the Roman Numeral kata in three different languages. Despite being a simple kata we have learned something about the Dictionary data structure, mainly that it does not have an order and thus should not be used in cases in which order matters.
Saturday, January 2, 2016
Discoveries in 2015
"So Jove, the Olympian Lord of Thunder, hied him to the bed in which he always slept; and when he had got on to it he went to sleep, with Juno of the golden throne by his side."
-- The Iliad, Homer
Book 1
My discoveries in 2015 of things that I've enjoyed (idea from Michael Fogus' Best Things and Stuff of 2015). Order is just ordered of discovery.
-- The Iliad, Homer
Book 1
My discoveries in 2015 of things that I've enjoyed (idea from Michael Fogus' Best Things and Stuff of 2015). Order is just ordered of discovery.
Programming Languages
Non-Fiction Books
- Zhuangzi: The Essential Writings by Zhuangzi
- Mastering Clojure Macros: Write Cleaner, Faster, Smarter Code by Colin Jones
- Against Method by Paul Feyerabend
- Type Theory and Formal Proof: An Introduction by Rob Nederpelt and Herman Geuvers
Fiction Books
- The Adventures of Sherlock Holmes by Arthur Conan Doyle
- David Copperfield by Charles Dickens
- Dracula by Bram Stoker
- La Cousine Bette by Honoré de Balzac
- La Chartreuse de Parme by Stendhal
White Papers
- "A tutorial on the universality and expressiveness of fold" by Graham Hutton
- "Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire" by Erik Meijer, Maarten Fokkinga, Ross Paterson
Music
My Top 5 Most Popular Blog Posts of 2015
- Intro to Higher Order Functions
- Think About Length OR How Fold Can Do Everything, Even Count
- Always Bet on Math
- Bro, Do You Even FizzBuzz?!?
- One Data Structure to Rule Them All
Most Enjoyable Conferences
Presented at: Midwest.io
Attended: Strange Loop
Location (Portland): Clojure/West
Sunday, December 13, 2015
Round and Round We Go OR How to Stop Circular References in AutoFixture
"That many things, having full reference"
-- Shakespeare, Henry V
Act I, Scene II, Line 205
I love to use AutoFixture to setup the the arrange part of my tests. I find that working without worrying about the arrange allows me to focus more on the task at hand. A possible downside of working this way is that AutoFixture is mindlessly setting up all the test data.
Having AutoFixture setup your test data is fine when working with green field classes but when working with legacy code and third party code you getting into cases in which you have circular references. What do I mean? Compare the following:
Case 1:
class A has members with type B
type B has member with type C
type C is a primitive
Case 2:
class X has members with type Y
type Y has member with type Z
type Z has member with type X
In case 1 we have a termination point with type C, AutoFixture can happily go about and create an instance of A and populate all the members in the hierarchy with data.
In case 2 we do not have a termination point, Z has a member of type X which a member of type Y which a member of type Z which goes back to X and so on. Case 2 has a circular reference and AutoFixture is unable to give us back an instance of X without going into an endless loop. Luckily AutoFixture is smart enough to figure out that it is in an endless loop and will error out telling us about the issue.
What do we do if we have a class like X in legacy code or third party code? We'll we can tell AutoFixture that we will have classes like X but that it is fine to just terminate the repeating hierarchy with a null or empty. We use the following to do that:
I normally put this in my TestInitialize for the test class of the offender, but I can see putting in the arrange of a test class if you are mixing old and new. There you have it, a way to use AutoFixture with dirty old classes.
-- Shakespeare, Henry V
Act I, Scene II, Line 205
I love to use AutoFixture to setup the the arrange part of my tests. I find that working without worrying about the arrange allows me to focus more on the task at hand. A possible downside of working this way is that AutoFixture is mindlessly setting up all the test data.
Having AutoFixture setup your test data is fine when working with green field classes but when working with legacy code and third party code you getting into cases in which you have circular references. What do I mean? Compare the following:
Case 1:
class A has members with type B
type B has member with type C
type C is a primitive
Case 2:
class X has members with type Y
type Y has member with type Z
type Z has member with type X
In case 1 we have a termination point with type C, AutoFixture can happily go about and create an instance of A and populate all the members in the hierarchy with data.
In case 2 we do not have a termination point, Z has a member of type X which a member of type Y which a member of type Z which goes back to X and so on. Case 2 has a circular reference and AutoFixture is unable to give us back an instance of X without going into an endless loop. Luckily AutoFixture is smart enough to figure out that it is in an endless loop and will error out telling us about the issue.
What do we do if we have a class like X in legacy code or third party code? We'll we can tell AutoFixture that we will have classes like X but that it is fine to just terminate the repeating hierarchy with a null or empty. We use the following to do that:
I normally put this in my TestInitialize for the test class of the offender, but I can see putting in the arrange of a test class if you are mixing old and new. There you have it, a way to use AutoFixture with dirty old classes.
Sunday, December 6, 2015
AutoFixture for the Win
"What have I kept back?"
-- Shakespeare, Antony and Cleopatra
Act V, Scene II, Line 147.2
Anyone who has paired with me while working in C# knows that I am addicted to AutoFixture. Now I do not try to add it to everything that I am working, but usually it finds its way into whatever I am working on. Why? Simply put, using AutoFixture allows me to focus on the task at hand.
Here is a quick example:
In this example I am implementing the higher order function Map using the higher order function Fold (see my other post if this interested you).
What do you not see in the tests? The setting up of the test data.
Why? It is not important to the task at hand. We do not need it to test the behavior of Map. Map takes a collection and a function and applies the function against every member of the collection producing a new collection. What we want to verify is the applies part, which only requires a collection and a function, the actual members of the collection (and the function) do not matter for this verification.
Staying focus on the task at hand is the power of a test fixture and having someone else implement the test fixture for you is even better. Using AutoFixture with xUnit you really do not need to think about setting up test data at all and that is good thing.
-- Shakespeare, Antony and Cleopatra
Act V, Scene II, Line 147.2
Anyone who has paired with me while working in C# knows that I am addicted to AutoFixture. Now I do not try to add it to everything that I am working, but usually it finds its way into whatever I am working on. Why? Simply put, using AutoFixture allows me to focus on the task at hand.
Here is a quick example:
In this example I am implementing the higher order function Map using the higher order function Fold (see my other post if this interested you).
What do you not see in the tests? The setting up of the test data.
Why? It is not important to the task at hand. We do not need it to test the behavior of Map. Map takes a collection and a function and applies the function against every member of the collection producing a new collection. What we want to verify is the applies part, which only requires a collection and a function, the actual members of the collection (and the function) do not matter for this verification.
Staying focus on the task at hand is the power of a test fixture and having someone else implement the test fixture for you is even better. Using AutoFixture with xUnit you really do not need to think about setting up test data at all and that is good thing.
Saturday, November 28, 2015
Axioms of Equal in Clojure
"In quantity equals not one of yours."
-- Shakespeare, Henry IV Part I
Act III, Scene I, Line 93
In The Little Prover we find the following Axioms of Equal:
(dethm equal-same (x)
(equal (equal x x) 't))
(dethm equal-swap (x y)
(equal (equal x y) (equal y x)))
(dethm equal-if (x y)
(if (equal x y
(equal x y)
't)))
I learn best by doing, so I showed myself these axioms in Clojure.
Looking at equal-same we see that if we have something which is the same then those values are equal. Nothing shocking, unless you are using reference equivalence which we are not.
Next we look at equal-swap which states that equivalence is commutative meaning x = y is the same as y = x. Again nothing shocking.
Last we look at equal-if which states that if something is equal once it will be equal again. Note that this assumes that values are immutable which they are (for the most part) in Clojure. This axiom is rather interesting when paired with lazy evaluation, as we see with the following:
(is (true?
(if (= :yep :yep)
(= :yep :yep)
(throw
(IllegalStateException. "How the hell did we get here?")))))
When the statement is evaluated we do not have the Exception thrown! This is a great benefit of the if special form in Clojure. We do see this awesomeness has limits:
(let [x (repeat 42)
y x]
(is (true?
(if (= x y)
(= x y)
false))))
but fails when the infinite sequence is not the same "reference"
(let [x (repeat 42)
y (repeat 42)]
(is (true?
(if (= x y)
(= x y)
false)))))
Despite the second example of comparing with an infinite sequence not finishing, the if special form is awesome and shows the power of the equal-if axiom paired with lazy evaluation.
These axioms are very powerful and I would argue are more useful than tests. If this interests you I would recommend reading The Little Prover or working your way through the flying tour of ACL2.
-- Shakespeare, Henry IV Part I
Act III, Scene I, Line 93
In The Little Prover we find the following Axioms of Equal:
(dethm equal-same (x)
(equal (equal x x) 't))
(dethm equal-swap (x y)
(equal (equal x y) (equal y x)))
(dethm equal-if (x y)
(if (equal x y
(equal x y)
't)))
I learn best by doing, so I showed myself these axioms in Clojure.
Looking at equal-same we see that if we have something which is the same then those values are equal. Nothing shocking, unless you are using reference equivalence which we are not.
Next we look at equal-swap which states that equivalence is commutative meaning x = y is the same as y = x. Again nothing shocking.
Last we look at equal-if which states that if something is equal once it will be equal again. Note that this assumes that values are immutable which they are (for the most part) in Clojure. This axiom is rather interesting when paired with lazy evaluation, as we see with the following:
(is (true?
(if (= :yep :yep)
(= :yep :yep)
(throw
(IllegalStateException. "How the hell did we get here?")))))
When the statement is evaluated we do not have the Exception thrown! This is a great benefit of the if special form in Clojure. We do see this awesomeness has limits:
(let [x (repeat 42)
y x]
(is (true?
(if (= x y)
(= x y)
false))))
but fails when the infinite sequence is not the same "reference"
(let [x (repeat 42)
y (repeat 42)]
(is (true?
(if (= x y)
(= x y)
false)))))
Despite the second example of comparing with an infinite sequence not finishing, the if special form is awesome and shows the power of the equal-if axiom paired with lazy evaluation.
These axioms are very powerful and I would argue are more useful than tests. If this interests you I would recommend reading The Little Prover or working your way through the flying tour of ACL2.
Sunday, November 22, 2015
Axioms of If in Clojure
"How if I answer no?"
-- Shakespeare, Hamlet
Act V, Scene II, Line 167
In The Little Prover we find the following Axioms of If:
(dethm if-true (x y)
(equal (if 't x y) x))
(dethm if-false (x y)
(equal (if 'nil x y) y)
(dethm if-same (x y)
(equal (if x y y) y)
(dethm if-nest-A (x y z)
(if x
(equal (if x y z) y)
't))
(dethm if-nest-E (x y z)
(if x
't
(equal (if x y z) z)))
The way I learn best is bytrying doing, so I showed myself these axioms in Clojure.
Looking at if-true we see that if we have a true premise that we always take the answer part of the if.
(if premise answer else)
This is not a shock to anyone, but is very useful.
Moving on we see if-false states that if we have a false premise that we always take the else part of the if. Again nothing shocking but very useful.
Next we see if-same which states that if the answer and else are the same then the premise does not matter. This makes complete logical sense, but I'll admit I never really thought of it before.
Now let us look at if-nest-A which states that if the condition is true in the premise then it must be true in the answer part. This is very awesome, we can now eliminate code by simply looking for redundant ifs. We see this in the following:
given x is true
(if x
(if x :yep :nope)
:nope)))))
We see that we have the(if what-ever in the outside which matches the (if what-ever in the answer part thus we can eliminate it pulling it up (in the code above the :yep), since if the premise is true on the outside it is true on the inside. This axiom is very useful in refactoring code and I figured it out for myself a long time ago and find myself using it all the time, it is nice to know that it has a solid theoretical basis.
Last we see the anti of if-nest-A, if-nest-E. if-nest-E states that if the condition is false in the premise then it must be false in the else part. We see this in the following:
given x is false
(if x
:nope
(if x :nope :yep))
We see that we have the (if what-ever in the outside which matches the (if what-ever in the else part thus we can eliminate it pulling it up (in the code above the :yep), since if the premise is false on the outside it is false on the inside. Again, this is very useful in eliminating code.
These axioms are very powerful and I would argue are more useful than tests. If this interests you I would recommend reading The Little Prover or working your way through the flying tour of ACL2.
-- Shakespeare, Hamlet
Act V, Scene II, Line 167
In The Little Prover we find the following Axioms of If:
(dethm if-true (x y)
(equal (if 't x y) x))
(dethm if-false (x y)
(equal (if 'nil x y) y)
(dethm if-same (x y)
(equal (if x y y) y)
(dethm if-nest-A (x y z)
(if x
(equal (if x y z) y)
't))
(dethm if-nest-E (x y z)
(if x
't
(equal (if x y z) z)))
The way I learn best is by
Looking at if-true we see that if we have a true premise that we always take the answer part of the if.
(if premise answer else)
This is not a shock to anyone, but is very useful.
Moving on we see if-false states that if we have a false premise that we always take the else part of the if. Again nothing shocking but very useful.
Next we see if-same which states that if the answer and else are the same then the premise does not matter. This makes complete logical sense, but I'll admit I never really thought of it before.
Now let us look at if-nest-A which states that if the condition is true in the premise then it must be true in the answer part. This is very awesome, we can now eliminate code by simply looking for redundant ifs. We see this in the following:
given x is true
(if x
(if x :yep :nope)
:nope)))))
We see that we have the(if what-ever in the outside which matches the (if what-ever in the answer part thus we can eliminate it pulling it up (in the code above the :yep), since if the premise is true on the outside it is true on the inside. This axiom is very useful in refactoring code and I figured it out for myself a long time ago and find myself using it all the time, it is nice to know that it has a solid theoretical basis.
Last we see the anti of if-nest-A, if-nest-E. if-nest-E states that if the condition is false in the premise then it must be false in the else part. We see this in the following:
given x is false
(if x
:nope
(if x :nope :yep))
We see that we have the (if what-ever in the outside which matches the (if what-ever in the else part thus we can eliminate it pulling it up (in the code above the :yep), since if the premise is false on the outside it is false on the inside. Again, this is very useful in eliminating code.
These axioms are very powerful and I would argue are more useful than tests. If this interests you I would recommend reading The Little Prover or working your way through the flying tour of ACL2.
Sunday, November 15, 2015
Axioms of Cons in Clojure
"Why then, build me thy fortunes upon the basis"
-- Shakespeare, Twelfth Night
Act III, Scene II, Line 31
I recently finished The Little Prover. In The Little Prover we find the following Axioms of Con:
(dethm atom/cons (x y)
(equal (atom (cons x y)) 'nil)
(dethm car/cons (x y)
(equal (car (cons x y)) x))
(dethm cdr/cons (x y)
(equal (cdr (cons x y)) y))
(dethm cons/car+cdr (x)
(if (atom x)
't
(equal (cons (car x) (cdr x)) x)))
The way I learn best is by showing myself that something makes sense, so I went through showing myself these axioms in Clojure.
Looking at atom/cons in the code above we see that Clojure does not have atom but (complement sequential?) is close enough if we are working with sequential collections so we'll use that. Using the definition that an atom is not a sequential collection we see in the code above that cons "always" yields not an atom.
Next looking at car/cons in the code above we see that using first (Clojure's car) on a cons "always" yields the head of the sequential collection, which makes prefect sense since that is what one expects from first.
The other side of car/cons is cdr/cons. Looking at the code above we see that using rest (Clojure's cdr) on a cons "always" yields the tail of the sequential collection, which again makes prefect sense since that is what one expects from rest.
Last we look at cons/car+cdr. Looking at the code we see that if we do not have an atom that first and rest (Clojure's car and cdr) together yield the sequential collection, which again is what one would expect.
So what does any of this give us? We now have a firm foundation on which to define other theorems and proofs about our statements using these axioms as our basis. This is very powerful and I would argue that this is better having tests.
If this interests you I would recommend reading The Little Prover or working your way through the flying tour of ACL2.
-- Shakespeare, Twelfth Night
Act III, Scene II, Line 31
I recently finished The Little Prover. In The Little Prover we find the following Axioms of Con:
(dethm atom/cons (x y)
(equal (atom (cons x y)) 'nil)
(dethm car/cons (x y)
(equal (car (cons x y)) x))
(dethm cdr/cons (x y)
(equal (cdr (cons x y)) y))
(dethm cons/car+cdr (x)
(if (atom x)
't
(equal (cons (car x) (cdr x)) x)))
The way I learn best is by showing myself that something makes sense, so I went through showing myself these axioms in Clojure.
Looking at atom/cons in the code above we see that Clojure does not have atom but (complement sequential?) is close enough if we are working with sequential collections so we'll use that. Using the definition that an atom is not a sequential collection we see in the code above that cons "always" yields not an atom.
Next looking at car/cons in the code above we see that using first (Clojure's car) on a cons "always" yields the head of the sequential collection, which makes prefect sense since that is what one expects from first.
The other side of car/cons is cdr/cons. Looking at the code above we see that using rest (Clojure's cdr) on a cons "always" yields the tail of the sequential collection, which again makes prefect sense since that is what one expects from rest.
Last we look at cons/car+cdr. Looking at the code we see that if we do not have an atom that first and rest (Clojure's car and cdr) together yield the sequential collection, which again is what one would expect.
So what does any of this give us? We now have a firm foundation on which to define other theorems and proofs about our statements using these axioms as our basis. This is very powerful and I would argue that this is better having tests.
If this interests you I would recommend reading The Little Prover or working your way through the flying tour of ACL2.
Sunday, November 8, 2015
Showing Map Distributes Over Functional Composition OR Fun With Clojure
"Here by the cheeks I'll drag thee up and down."
-- Shakespeare, Henry VI Part 1
Act I, Scene III, Line 51
I love to try things out for myself. Whenever I am trying to understand idea I need to show myself that the idea is valid. Sometimes I will just accept something, but if I really want to understand it I will show myself that it makes sense.
While rereading Dr. Hutton's paper "A tutorial on the universality and expressiveness of fold", I came back across the following statement, "the map operator distributes over function composition". Being the kind of person which likes to show things to myself I figured I'd show myself this idea in Clojure as part of my daily kata.
Looking at the code above we see the following:
So what does this give us? Having this property we are allowed to improve the performance of our code by composing a series of transformation against a collection to a single transformation of the collection dragged through a series of composed functions. In fact this is the whole idea behind streams.
Taken straight from Raoul-Gabriel Urma's article in Java Magazine, "[i]n a nutshell, collections are about data and streams are about computations." Thinking about processing as a series of computation we see how we can naturally think about composing our computations together and then drag the data through using a higher order function like map to preform the series of transformations in one pass.
-- Shakespeare, Henry VI Part 1
Act I, Scene III, Line 51
I love to try things out for myself. Whenever I am trying to understand idea I need to show myself that the idea is valid. Sometimes I will just accept something, but if I really want to understand it I will show myself that it makes sense.
While rereading Dr. Hutton's paper "A tutorial on the universality and expressiveness of fold", I came back across the following statement, "the map operator distributes over function composition". Being the kind of person which likes to show things to myself I figured I'd show myself this idea in Clojure as part of my daily kata.
Looking at the code above we see the following:
- map f · map g = map (f · g)
- r/map f · r/map g = r/map (f · g)
- reduction f · reduction g = reduction (f · g)
So what does this give us? Having this property we are allowed to improve the performance of our code by composing a series of transformation against a collection to a single transformation of the collection dragged through a series of composed functions. In fact this is the whole idea behind streams.
Taken straight from Raoul-Gabriel Urma's article in Java Magazine, "[i]n a nutshell, collections are about data and streams are about computations." Thinking about processing as a series of computation we see how we can naturally think about composing our computations together and then drag the data through using a higher order function like map to preform the series of transformations in one pass.
Sunday, October 18, 2015
On the Fusion Property of Fold
"If I break time, or flinch in property"
-- Shakespeare, All's Well That Ends Well
Act II, Scene I, Line 187
In Dr. Hutton's excellent paper, "A tutorial on the universality and expressiveness of fold", he gives the following definition of the fusion property of Fold:
h · fold g w = fold f v
Great, but what does this mean to me? Well if we go on in the paper we find the following application of the fusion property of Fold:
(+1) · sum = fold (+) 1
Interesting, we see that adding 1 to the sum (defined as, fold (+) 0) of a collection is the same as folding over that collection with 1 as the seed value. Further down in the paper we see that we can simplify and generalize the application above as:
(⊕ a) · fold (⊕) b = fold (⊕) (b ⊕ a)
Now this is really cool. We can apply an associative binary operation with a value against the results of folding that operation against a collection is the same as applying that binary operation with a value against the seed.
As an aside, an associative binary operation is an operation which takes two values from the same type and outputs a value of that type, examples would be +, -, *, /, min, max, ... We say an operation is associative if and only if:
a ⊕ b = b ⊕ a
This means addition is associative while subtraction is not (2 - 1 != 1 - 2, but 2 + 1 = 1 + 2).
How about looking at some examples of the fusion property?
First we'll look at examples in Clojure.
We see in the Clojure example that we are using reduce to fold over a collection of integers (integers are easier to use in examples but this idea is not limited to integers) applying an associative binary operation against each member. We see that applying the operation with a value against the result is the same as applying that operation and value against the seed.
Next we'll look at examples in ECMAScript 2015 (JavaScript) using Immutable.js.
We see in the ECMAScript example that we are using Immutable's reduce to fold over a List of integers (again this could be applied against any type) applying the associative binary operation against the members. Like the Clojure example we see that applying the operation with a value against the result is the same as applying that operation and value against the seed.
We can go further with this idea but I feel this is a good overview of the concept.
-- Shakespeare, All's Well That Ends Well
Act II, Scene I, Line 187
In Dr. Hutton's excellent paper, "A tutorial on the universality and expressiveness of fold", he gives the following definition of the fusion property of Fold:
h · fold g w = fold f v
Great, but what does this mean to me? Well if we go on in the paper we find the following application of the fusion property of Fold:
(+1) · sum = fold (+) 1
Interesting, we see that adding 1 to the sum (defined as, fold (+) 0) of a collection is the same as folding over that collection with 1 as the seed value. Further down in the paper we see that we can simplify and generalize the application above as:
(⊕ a) · fold (⊕) b = fold (⊕) (b ⊕ a)
Now this is really cool. We can apply an associative binary operation with a value against the results of folding that operation against a collection is the same as applying that binary operation with a value against the seed.
As an aside, an associative binary operation is an operation which takes two values from the same type and outputs a value of that type, examples would be +, -, *, /, min, max, ... We say an operation is associative if and only if:
a ⊕ b = b ⊕ a
This means addition is associative while subtraction is not (2 - 1 != 1 - 2, but 2 + 1 = 1 + 2).
How about looking at some examples of the fusion property?
First we'll look at examples in Clojure.
We see in the Clojure example that we are using reduce to fold over a collection of integers (integers are easier to use in examples but this idea is not limited to integers) applying an associative binary operation against each member. We see that applying the operation with a value against the result is the same as applying that operation and value against the seed.
Next we'll look at examples in ECMAScript 2015 (JavaScript) using Immutable.js.
We see in the ECMAScript example that we are using Immutable's reduce to fold over a List of integers (again this could be applied against any type) applying the associative binary operation against the members. Like the Clojure example we see that applying the operation with a value against the result is the same as applying that operation and value against the seed.
We can go further with this idea but I feel this is a good overview of the concept.
Sunday, October 11, 2015
Folding Up the Coin Changer Kata
"Whate'er the course, the end is the renown."
-- Shakespeare, All's Well That Ends Well
Act IV Scene IV, Line 36
The Coin Changer kata has three things which make it a good kata.
The user story is very simple:
Given a collection of coins of different denominational value
When an amount of change is given
Then it will give back the number of coins for each denomination needed using the least amount of coins possible
A type signature for the function needed could look like the following:
changeFor(coins: int[], amount: int): int[]
We are expecting an array of integers which have different denomination of coins (in the US something like: [25, 10, 5, 1]) and the amount of change needed (something like: 99) giving a resulting array of integers showing how many of each denomination (something like: [3, 2, 0, 4]).
What would we need to be able to do this kata using just Fold?
We'll need to use a tuple (or something like one) to manage the state of the amount of change needed and the resulting array of integers.
Now lets look at an example using a typical full US register with quarters, dimes, nickels, and pennies. We'll look at getting change for 99 cents.
First Memorize has (99, empty) and X has 25 giving the result of (24, [3]).
Next Memorize has (24, [3]) and X has 10 giving the result of (4, [3, 2]).
Then Memorize has (4, [3, 2]) and X has 5 giving the result of (4, [3, 2, 0]).
Last Memorize has (4, [3, 2, 0]) and X has 1 giving the result of (0, [3, 2, 0, 4]).
Finally obtaining the tuple item with the resulting array of integers to get the change.
We see with the Clojure code that we seed with a map with a key for the :amount and one for the :result. We fold over the coins using reduce destructing the memoize value into the amount and result. We then just calculate the new amount using: amount % coin, follow by inserting the number of coins we get using: amount / coin. We use cons to show off the coolness that is the thread-last macro (at least that is why I think I coded it this way, it was a little bit ago that I did the gist and I cannot remember why I code with cons over conj).
We see with the C# code that we seed using a Tuple (which I think has very ugly syntax in C#). We then fold over the coins using aggregate just like the Clojure code above. We calculate the changer results and place them into a new Tuple which we return as the memoize.
In this ECAMScript 2015 example we use lodash's foldl to fold over the coins just like the two examples above. The seed value is a simple JavaScript object with the members of amount and result given. We are a bit dirty and mutate the memoize on each call with the changer results but we could argue that this is still "pure" since the mutation happens to an item which is created and used only in side the function.
Last we look at Facebook's open source Immutable.js. We create an immutable List with the coins which we use to fold over the values using reduce. The seed value we give it is a simple JavaScript array with an immutable List to hold the results and the amount passed in. We could use an immutable Map if we wanted to keep it purely immutable. Like this:
I am not a huge fan of stringly typed accessors, but I understand why they use them. Both ways are good and would really come down to to performance and readability.
Thus ends our tour of All You Need is Fold, but this is not the end of the uses of Fold, for Fold is universal.
-- Shakespeare, All's Well That Ends Well
Act IV Scene IV, Line 36
Coin Changer Kata
The Coin Changer kata has three things which make it a good kata.
- easy to understand
- rich set of features
- lots of realistic possible implementations
The user story is very simple:
Given a collection of coins of different denominational value
When an amount of change is given
Then it will give back the number of coins for each denomination needed using the least amount of coins possible
A type signature for the function needed could look like the following:
changeFor(coins: int[], amount: int): int[]
We are expecting an array of integers which have different denomination of coins (in the US something like: [25, 10, 5, 1]) and the amount of change needed (something like: 99) giving a resulting array of integers showing how many of each denomination (something like: [3, 2, 0, 4]).
What would we need to be able to do this kata using just Fold?
We'll need to use a tuple (or something like one) to manage the state of the amount of change needed and the resulting array of integers.
Now lets look at an example using a typical full US register with quarters, dimes, nickels, and pennies. We'll look at getting change for 99 cents.
First Memorize has (99, empty) and X has 25 giving the result of (24, [3]).
Next Memorize has (24, [3]) and X has 10 giving the result of (4, [3, 2]).
Then Memorize has (4, [3, 2]) and X has 5 giving the result of (4, [3, 2, 0]).
Last Memorize has (4, [3, 2, 0]) and X has 1 giving the result of (0, [3, 2, 0, 4]).
Finally obtaining the tuple item with the resulting array of integers to get the change.
Clojure
We see with the Clojure code that we seed with a map with a key for the :amount and one for the :result. We fold over the coins using reduce destructing the memoize value into the amount and result. We then just calculate the new amount using: amount % coin, follow by inserting the number of coins we get using: amount / coin. We use cons to show off the coolness that is the thread-last macro (at least that is why I think I coded it this way, it was a little bit ago that I did the gist and I cannot remember why I code with cons over conj).
C#
We see with the C# code that we seed using a Tuple (which I think has very ugly syntax in C#). We then fold over the coins using aggregate just like the Clojure code above. We calculate the changer results and place them into a new Tuple which we return as the memoize.
ECMAScript 2015
In this ECAMScript 2015 example we use lodash's foldl to fold over the coins just like the two examples above. The seed value is a simple JavaScript object with the members of amount and result given. We are a bit dirty and mutate the memoize on each call with the changer results but we could argue that this is still "pure" since the mutation happens to an item which is created and used only in side the function.
ECMAScript 2015 and Immutable.js
Last we look at Facebook's open source Immutable.js. We create an immutable List with the coins which we use to fold over the values using reduce. The seed value we give it is a simple JavaScript array with an immutable List to hold the results and the amount passed in. We could use an immutable Map if we wanted to keep it purely immutable. Like this:
I am not a huge fan of stringly typed accessors, but I understand why they use them. Both ways are good and would really come down to to performance and readability.
The End
Thus ends our tour of All You Need is Fold, but this is not the end of the uses of Fold, for Fold is universal.
Sunday, October 4, 2015
Fold the Zip Up
"They fell together all, as by consent."
-- Shakespeare, The Tempest
Act II, Scene I, Line 207
Zip can be thought of as the more generic form of Map. Think of Zip as applying a function against each member of the collections given to it, thus mapping more than one collection to another collection. It is a lot easier to see than to explain in words.
I believe Zip2 would get the following definition:
zip2 :: (α → β → γ) → ([α] → [β] → [γ])
zip2 f = fold (λx y xs ys → f x y : xs ys) [ ]
This would be if we limit Zip to being used on 2 collections (this is mine definition, Dr. Graham Hutton has nothing to do with this definition, blame me if it is wrong).
Folding a Zip we'll need a collection to seed with then we just apply the given function against each member from each collection concatenating it with the seed, just as we did with Map.
Next we'll look at a simple example adding the members of two collections together.
First Memoize has nothing and X has 1 while Y has 10 giving the result of 11.
Next Memoize has 11 and X has 2 while Y has 20 giving the result of 11, 22.
Lets see some code examples.
With Clojure we do not have to worry about the number of collection we'll give our Zip function since we can use destructing to say and everything else. We can then apply map to create a vector containing all the elements next to each other, we'll see this is common in the other languages since the implementation of reduce is only design to work with a single collection. From here it is just like Map except that we need to use apply since are members are a collection themselves.
With C# we have to specify the number of collection we are going to Zip, in this case we'll do two. We need to Zip the members from the two collections together into a Tuple (which is a bit of cheating but I can find no other way to do it with LINQ). From there it is just like Map. With this implementation we do have a limitation in that the two collections must be the same size, since to get around that would be a bit of work and we rather have a readable implementation than perfect code.
In ECMAScript 2015 (also known as JavaScript ES6), we see an implementation similar to the C# code except we use lodash's zip to place the members in a single collection (lodash's zipWith is like LINQ's Zip). From there it is just like Map. With this implementation like the C# implementation we have a limitation in that the two collections must be the same size, and again the work around would be a lot of work so we'll error on keeping the code readable.
There you have it showing once again that all you need is Zip.
-- Shakespeare, The Tempest
Act II, Scene I, Line 207
Zip
Zip can be thought of as the more generic form of Map. Think of Zip as applying a function against each member of the collections given to it, thus mapping more than one collection to another collection. It is a lot easier to see than to explain in words.
I believe Zip2 would get the following definition:
zip2 :: (α → β → γ) → ([α] → [β] → [γ])
zip2 f = fold (λx y xs ys → f x y : xs ys) [ ]
This would be if we limit Zip to being used on 2 collections (this is mine definition, Dr. Graham Hutton has nothing to do with this definition, blame me if it is wrong).
Folding a Zip we'll need a collection to seed with then we just apply the given function against each member from each collection concatenating it with the seed, just as we did with Map.
Next we'll look at a simple example adding the members of two collections together.
First Memoize has nothing and X has 1 while Y has 10 giving the result of 11.
Next Memoize has 11 and X has 2 while Y has 20 giving the result of 11, 22.
Lets see some code examples.
Clojure
With Clojure we do not have to worry about the number of collection we'll give our Zip function since we can use destructing to say and everything else. We can then apply map to create a vector containing all the elements next to each other, we'll see this is common in the other languages since the implementation of reduce is only design to work with a single collection. From here it is just like Map except that we need to use apply since are members are a collection themselves.
C#
With C# we have to specify the number of collection we are going to Zip, in this case we'll do two. We need to Zip the members from the two collections together into a Tuple (which is a bit of cheating but I can find no other way to do it with LINQ). From there it is just like Map. With this implementation we do have a limitation in that the two collections must be the same size, since to get around that would be a bit of work and we rather have a readable implementation than perfect code.
ECMAScript 2015
In ECMAScript 2015 (also known as JavaScript ES6), we see an implementation similar to the C# code except we use lodash's zip to place the members in a single collection (lodash's zipWith is like LINQ's Zip). From there it is just like Map. With this implementation like the C# implementation we have a limitation in that the two collections must be the same size, and again the work around would be a lot of work so we'll error on keeping the code readable.
Done
There you have it showing once again that all you need is Zip.
Sunday, September 20, 2015
The Cloud-Capped Towers OR AutoFixture
"The cloud-capped towers, the gorgeous palaces,
The solemn temples, the great globe itself,
Yea, all which it inherit, shall dissolve,
And, like this insubstantial pageant faded,
Leave not a rack behind. We are such stuff"
-- Shakespeare, The Tempest
Act IV, Scene I, Lines 152 -156
In my day-to-day work I do a lot of .Net programming. It seem at some point in each of the applications I am either enhancing or creating I ended including Mark Seemann's AutoFixture (if it is not already in use). AutoFixture is an easy way to create a fixture object. A fixture object is an object which centralizes your helper methods in your test code, like methods which create your system under test and help generate test data.
Fixture objects are great and I often find myself wanting one in my day-to-day work, but I am lazy. Since I am lazy I do not want to go to all the trouble of creating my own fixture object, to quote Homer Simpson, "Can't someone else do it". Luckily in the .Net realm someone already has, Mark Seemann. AutoFixture lets you get the best of all worlds, you get a fixture object and you do not have to write the framework around it! (working with it for a few years now, I can say it is well thought out and not a big hair ball, see also Simple Made Easy for the full reference)
How about some examples? (taken from the AutoFixture cheat sheet and rewritten using xUnit)
We see in the above lots of wonderful things.
Another framework I use a lot in my day-to-day .Net programming is Moq. Guess what, AutoFixture can be uses as an auto-mocking container with Moq (and it has plugins for other mocking frameworks too).
Yet another example. (using MS Test taken from an overview of AutoFixture I did at work recently)
We see in this example that we had a simple class called Echo which got top hatted into having logging and a backup added to it. The interactions with the logger and back-upper need to be tested, luckily we can tell the fixture object that we would like to get spy objects for the logger and back-upper. These spies from AutoFixture are Moq mocks which allows us to verify that the behaviors we want.
By using AutoFixture and Moq we can meet all the "needs" of Top Hats everywhere.
(The term Top Hats comes from Uncle Bob's Clean Coder series episode 7, in which there is a scene with an Architect talking about choosing an IDE and Database for a project hence the term Top Hat and top hatting to describe this type of "architecture".)
I find that AutoFixture allows me to simplify my test code (simple as discussed in Simple Made Easy) and allows me to stay focus on what I am actually trying to test.
The solemn temples, the great globe itself,
Yea, all which it inherit, shall dissolve,
And, like this insubstantial pageant faded,
Leave not a rack behind. We are such stuff"
-- Shakespeare, The Tempest
Act IV, Scene I, Lines 152 -156
In my day-to-day work I do a lot of .Net programming. It seem at some point in each of the applications I am either enhancing or creating I ended including Mark Seemann's AutoFixture (if it is not already in use). AutoFixture is an easy way to create a fixture object. A fixture object is an object which centralizes your helper methods in your test code, like methods which create your system under test and help generate test data.
Fixture objects are great and I often find myself wanting one in my day-to-day work, but I am lazy. Since I am lazy I do not want to go to all the trouble of creating my own fixture object, to quote Homer Simpson, "Can't someone else do it". Luckily in the .Net realm someone already has, Mark Seemann. AutoFixture lets you get the best of all worlds, you get a fixture object and you do not have to write the framework around it! (working with it for a few years now, I can say it is well thought out and not a big hair ball, see also Simple Made Easy for the full reference)
How about some examples? (taken from the AutoFixture cheat sheet and rewritten using xUnit)
We see in the above lots of wonderful things.
- We can walk up to the fixture object and ask it for some test data.
- We can use the AutoData attribute and ask for test data.
- We can register implementation for abstract types.
- We can create collections of test data.
- We can build specific test data saying what attributes we care about and letting the fixture object set up the rest.
- We can even have a do method to allow for modification outside of the object we are having the fixture object create (this is not good design but sometimes it is needed).
Another framework I use a lot in my day-to-day .Net programming is Moq. Guess what, AutoFixture can be uses as an auto-mocking container with Moq (and it has plugins for other mocking frameworks too).
Yet another example. (using MS Test taken from an overview of AutoFixture I did at work recently)
We see in this example that we had a simple class called Echo which got top hatted into having logging and a backup added to it. The interactions with the logger and back-upper need to be tested, luckily we can tell the fixture object that we would like to get spy objects for the logger and back-upper. These spies from AutoFixture are Moq mocks which allows us to verify that the behaviors we want.
By using AutoFixture and Moq we can meet all the "needs" of Top Hats everywhere.
(The term Top Hats comes from Uncle Bob's Clean Coder series episode 7, in which there is a scene with an Architect talking about choosing an IDE and Database for a project hence the term Top Hat and top hatting to describe this type of "architecture".)
I find that AutoFixture allows me to simplify my test code (simple as discussed in Simple Made Easy) and allows me to stay focus on what I am actually trying to test.
Sunday, September 13, 2015
Filter, Guarding You From Fold
"You and your ways; whose wraths to guard you from,"
A simple example would be a filtering with a function which says if a value is odd or not.
-- Shakespeare, The Tempest
Filter
Filter is a lot like a higher order functional bouncer, it prevents undesirable elements from getting into the resulting collection.
A simple example would be a filtering with a function which says if a value is odd or not.
In Dr. Hutton's excellent paper, "A tutorial on the universality and expressiveness of fold", he gives the following definition of Filter in terms of Fold:
filter :: (α → Bool) → ([α] → [α])
filter p = fold (λx xs → if p x then x : xs else xs) [ ]
From the definition above, we see that Filter is just Map but with a predicate clause stating if the element should be placed in the resulting collection or not.
Let us look at an example using my name Mike and a function which will check if a character is lower case.
(similar to Map last time)
First Memoize has nothing and X has M.
Next Memoize still has nothing (since M is upper case) and X has i.
Now Memoize has i and X has k.
Then Memoize has i and k while X has e.
Now the Filter will return the result of "ike".
Now what we all came to see, some code examples.
Clojure
In Clojure we can use the reduce function to move through the collection checking the predicate condition with the if macro guard against undesirable elements.
C#
With the C# code we'll need to create some type of collection with the seed value which will allow us to add elements to it, we'll use the collection class of List. We'll simply iterate through the collection using Aggregate and add elements to the memoize List if they pass the predicate clause.
ECMAScript 2015
In the code above that we'll use the build in JavaScript array method of push to add an element which gets past the guarding predicate function to the array at the end. We are simply move through the collection we are filtering, pushing elements into the memoize array.
Fin
There you have it we are able to keep the riffraff elements out using Fold.
Subscribe to:
Posts (Atom)