Jay Hayes / iamvery.com

Best Hayes Ahead

Wed, 04 Sep 2024 00:00:00 -0500

For some time now, my wife and I have wanted to capture our stories a share them. Plenty of people start podcasts, so I suppose that’s nothing new. However, our vision is for sharing our stories and experiences so that they may help others on their own journey; I think that is something special. We’re announcing the launch of Best Hayes Ahead! This is how we podcast. We’ll be sharing stories from our past and hope for the future. I’ve even got ideas for some nerdy tangents :D. There’s really no telling where this will take us, so hop on board and let’s go!

Better LiveView Tests

Wed, 19 Oct 2022 00:00:00 -0500

In short, I want to take LiveView test from something like this:

 {:ok, index_live, _html} = live(conn, Routes.link_index_path(conn, :index))

 assert index_live |> element("#link-#{link.id} a", "Edit") |> render_click() =~ "Edit Link"

 {:ok, _, html} =
    index_live
    |> form("#link-form", link: @update_attrs)
    |> render_submit()
    |> follow_redirect(conn, Routes.link_index_path(conn, :index))

  assert html =~ "Link updated successfully"
  assert html =~ "some updated description"

To something like this:

start(conn, Routes.link_index_path(conn, :index))
|> click("#link-#{link.id} a", "Edit")
|> assert_html("Edit Link")
|> submit_form("#link-form", link: @update_attrs)
|> assert_html("Link updated successfully")
|> assert_html("some updated description")

I put together some helper functions which you can install with the Hex package https://hex.pm/packages/iamvery to achieve this.

Which do you think is easier to read? It’s not just about line count, it’s also about context switching. Read on.

Background

I’m just getting started with Phoenix LiveView, but thus far I’ve really enjoyed using it. One of the reasons I have enjoyed using LiveView is how it simplifies system testing by avoiding the need for a browser running in many cases. However, I have found the tests somewhat difficult to get my head around.

Here’s a full example test from the live generator.

test "updates link in listing", %{conn: conn, link: link} do
  {:ok, index_live, _html} = live(conn, Routes.link_index_path(conn, :index))

  assert index_live |> element("#link-#{link.id} a", "Edit") |> render_click() =~
           "Edit Link"

  assert_patch(index_live, Routes.link_index_path(conn, :edit, link))

  assert index_live
         |> form("#link-form", link: @invalid_attrs)
         |> render_change() =~ "can&#39;t be blank"

  {:ok, _, html} =
    index_live
    |> form("#link-form", link: @update_attrs)
    |> render_submit()
    |> follow_redirect(conn, Routes.link_index_path(conn, :index))

  assert html =~ "Link updated successfully"
  assert html =~ "some updated description"
end

While I do love that this test covers the system from the perspective of an interacting user, it also leaks a bit of underlying detail from the framework. Notably, there are three concepts to keep track of: the views, the rendered HTML documents, and the test conn.

This gets extra confusing depending on the functions being used. For example, the live/2 function returns the view and some rendered HTML which may be useful in different contexts depending on what you intend to do with them. The view is used on the next line to locate and click an element:

 assert index_live |> element("#link-#{link.id} a", "Edit") |> render_click() =~
           "Edit Link"

But the result of the click is used in an assertion in comparison with some text. That is because the render_click/1 function returns an HTML document.

Later on, the conn comes into play when there is a redirect.

|> follow_redirect(conn, Routes.link_index_path(conn, :index))

This toggling between views, html documents, and conns forces line breaks, but more importantly forces the reader to mentally juggle the value in context of each line.

I can imagine this gets a lot easier with experience, but I think we can do better from the start.

Test Helpers

To address the issue of context switching, we can introduce a set of test helpers that handle the context for you. Then, so long as you keep with the pattern, you don’t have to perform the mental gymnastics yourself. This essentially comes down to a set of helper functions that keep the conn, view, and document bundled together and forwarded along for you between steps.

You can find the full set of helpers here, but here are a few to illustrate the example.

def start(conn, path) do
  {conn, live(conn, path)}
end

def assert_html({conn, {:ok, view, html}}, expected_html) do
  assert html =~ expected_html
  {conn, {:ok, view, html}}
end

def click({conn, {:ok, view, _html}}, selector, text, opts \\ []) do
  html =
    view
    |> element(selector, text)
    |> render_click()

  if Keyword.get(opts, :follow, false) do
    {conn, follow_redirect(html, conn)}
  else
    {conn, {:ok, view, html}}
  end
end

As you can see, each helper function receives and returns the conn along with the typical “ok, view” return value from built-in helpers. By implementing a few more helpers in assert_path/2, change_form/3, submit_form/3 we can dramatically refactor the test and eliminate nearly all mention of these bits of context.

test "updates link in listing", %{conn: conn, link: link} do
  start(conn, Routes.link_index_path(conn, :index))
  |> click("#link-#{link.id} a", "Edit")
  |> assert_html("Edit Link")
  |> assert_path(Routes.link_index_path(conn, :edit, link))
  |> change_form("#link-form", link: @invalid_attrs)
  |> assert_html(escape("can't be blank"))
  |> submit_form("#link-form", link: @update_attrs)
  |> assert_html("Link updated successfully")
  |> assert_html("some updated description")
end

With that, you have a clean test written as a pipeline that insulates the reader from the state and relevant context that’s forwarded along.

I’m sure the helpers I have put together are incomplete, and you will have all manner of edge cases to help work out. However, you can tap in at any time to do something novel and you’ll always get {conn, {:ok, live, html}}. For the sake of testing the waters, I’ve published them in my namesake’s Hex package: https://hex.pm/packages/iamvery.

Let me know what you think!

Half-Truth

Wed, 12 Jan 2022 00:00:00 -0600

You know what doesn’t win friends? Calling people liars. Oh well, truth is truth, right? Yep. But what happens when you dilute the truth a little bit? It reminds me of an analogy my wife shared with me.

Would you eat a cake that had just a little bit of poop baked into it?

No, I suppose that changes things for me, and that’s about the same effect a little non-truth has on what is otherwise truthful.

half-truth a statement that conveys only part of the truth, especially one used deliberately in order to deceive someone

(New Oxford American Dictionary)

Does this sound familiar? This day in age you’re probably immediately thinking politicians and lawyers, and you’re probably not wrong. The part after the comma drives it home, though I would imagine that type of folk would make a small edit:

in order to ~~deceive~~ convince someone

Hold on. Don’t act all smug and innocent. You’ve done it too. Today? Half-truths are a particular problem, because not only are they used to deceive others, they sometimes even deceive you.

I haven’t had any ice cream this week [true], so I deserve a little treat [lie].

It seems such half-truths run rampant in our society today. They’re indescriminately shared by folks on every side of the political tesseract. Things like:

So and so voted for (Trump|Biden) [true], so they’re a major (racist|marxist) [lie]!

No, that’s not true. It may be true that of the card-carrying *ists most of them voted for one or the other, but to conclude that everyone else also falls into those categories is deceitful. It’s divisive, and I would say hateful. No one appreciates being labeled.

Truth is nowhere to be found, and whoever shuns evil becomes a prey. The LORD looked and was displeased that there was no justice.

Isaiah 59:15 NIV

Here’s a recent example:

…there are also people who are vehemently opposed to vaccination [true]. These are extremists [?] who do not believe in science [?], who are often [?] misogynists [?], often racists [?] too; it is a sect, a small [?] group, but who are taking up space…

(emphasis added)

Those are the (translated from French) words of the prime minister of Canada. Check out the labels: vehemently extremists, misogynists, racists, small. Ouch. Aïe.

What good is this doing for anyone? Does it make the unlabeled group feel good? What bad is it doing? We’re left feeling like we have to decide what camp we fall into, because the highest levels of our leadership are lumping us into categories based on empty rhetoric. Even if you agree with the message, you have to admit it’s strikingly divisive.

And you see this goes for practically every issue that’s being discussed today. We need to get better at disagreeing again. Respectfully. I’d even say it’s good for us. Sorry, I slid off track a little bit. Let’s get back to the truth…

The Truth

What is truth anyway? Where does it come from? Can it change? We hear about ”your truth“ and “my truth” now days, which sound a lot like opinions to me anyway. Turns out the question of truth is not what, it’s who.

Jesus answered, “I am the way and the truth and the life. No one comes to the Father except through me.

– John 14:6 NIV

Nice 🎯. And how exactly can a person be “the truth”?

The Word became flesh and made his dwelling among us. We have seen his glory, the glory of the one and only Son, who came from the Father, full of grace and truth.

– John 1:14 NIV

Got it, Jesus is the embodiment of God‘s word. The truth. This is great, what do we do with it?

Then you will know the truth, and the truth will set you free.

– John 8:32 NIV

Freedom is good. Let’s be free. If truth sets us free, what’s the opposite like?

Jesus replied, “Very truly I tell you, everyone who sins is a slave to sin.”

– John 8:34 NIV

Btw, lying is sin, and speaking half-truth is lying. The slave part sounds bad, but it gets a lot worse than that. We won’t get into all that right now, but about those lies…

The Lie

We were able to figure out the source of truth, so where do all the lies come from? Turns out, it started quiet awhile ago. In fact, it began with half-truths. They’re sometimes more potent than lies…

And the LORD God commanded the man, “You are free to eat from any tree in the garden; but you must not eat from the tree of the knowledge of good and evil, for when you eat from it you will certainly die.”

– Genesis 2:16-17

The father of lies must have heard God tell Adam and Eve this, but notice how he changes the message in relaying it back to Eve.

Now the serpent was more crafty than any of the wild animals the LORD God had made. He said to the woman, “Did God really say, ‘You must not eat [true] from any tree [lie] in the garden’?”

– Genesis 3:1 (emphasis added)

The half-truth is that God said not to eat of any tree. This sews doubt, and interestingly results in Eve herself responding in error.

The woman said to the serpent, “We may eat fruit from the trees in the garden, but God did say, ‘You must not eat fruit from the tree that is in the middle of the garden [true], and you must not touch it [lie], or you will die.’ ”

– Genesis 3:2-3 (emphasis added)

God never said anything about touching the tree. Also, interesting how vague the reference to the tree gets here; “middle of the garden”. Both of the special trees are described this way.

The LORD God made all kinds of trees grow out of the ground—trees that were pleasing to the eye and good for food. In the middle of the garden were the tree of life and the tree of the knowledge of good and evil.

– Genesis 2:9 (emphasis added)

So what does does the liar tell her?

“You will not certainly die,” the serpent said to the woman.

– Genesis 3:4

The TRUTH! The conversation has devolved enough at this point that this is easily interpretted as truth: 1) The tree of life is in the middle of the garden and won’t kill you and 2) touching is no problem.

“For God knows that when you eat from it your eyes will be opened, and you will be like God, knowing good and evil.”

– Genesis 3:5

God never said that, it was inferred from the name of the tree, but this conversation was enough to coerce Eve. Who knows what Eve’s intent was, but the fact remains that her next move was disabedience and the rest is history.

Half-truth has a dangerous tendancy of confusing us. Our perception of truth becomes warped as we loose track of what is true and what isn’t until we eventually believe a lie. Sprinkle in a little fear and you have all the ingredients for manipulation.

Even now, the pattern repeats itself in our society. Don’t believe the lie. Don’t buy into all the emotion and become manipulated. Hold fast to the Truth!

Be alert and of sober mind. Your enemy the devil prowls around like a roaring lion looking for someone to devour.

– 1 Peter 5:8 NIV

If you’re comfortable with lying, stop it.

You belong to your father, the devil, and you want to carry out your father’s desires. He was a murderer from the beginning, not holding to the truth, for there is no truth in him. When he lies, he speaks his native language, for he is a liar and the father of lies.

– John 8:44 NIV

It comes down to that. There’s an enemy trying to take you out. He hates you, and he wants you. Take hold of the Truth, and you’ll be free of the lies and evendeath. A half-truth is a whole lie.

Refocusing

Wed, 05 Jan 2022 00:00:00 -0600

I haven’t posted much online in awhile. My last post here was mid-2019. You see, 2019 was a transformational year for me. I backed off from speaking and travel and focused my time and attention at home on my family. It has been wonderful! As the year progressed, I realized that another significant source of distraction for me was social media. It wasn’t doing me any good (and I didn’t yet full appreciate how much bad it was doing). So I signed out, deleted apps, and stopped using the services completely as the year rolled over to 2020.

RIP:

https://twitter.com/iamvery (apparently now squatted by someone else)
https://facebook.com/iamvery

You can still find me at:

https://github.com/iamvery
https://iamvery.com

On the subject of social media…

A Problem

In my opinion social media is more bad than good. I sensed this was a generally accepted sentiment way back in 2019 around the time I scaled back. However, the past couple years have brought to light how insidious major tech companies can be, not to mention the power they wield. In this amount of time, we have seen content moderation go from something you occasionally hear about in regard to (terrible) things like pornography to significant personalities and businesses being wiped off platforms for violating website “standards”, citing violations of sharing certain information, the basis of which changes over time.

Perhaps particular situations come to mind. Perhaps they are controversial to you. Try to put our opinions of these specifics aside. Can we agree that having these major tech companies move (sometimes in unison) to silence individuals and businesses is problematic? Would you consider it problematic if it affected information you agree with? Can we agree that this is a form of censorship? And can we agree that there’s a notable bias in those who have been most affected? Is that really OK?

I remember how my skin crawled when I read that Parler had been wiped off the Internet, and it’s worth noting that I had barely even heard of it beforehand (I was not a user). I wanted to hop into my company’s chat and share my outrage with my coworkers. I wanted to post again on Twitter and other social media accounts. Heck, I even wanted to shout on the street corner… But I didn’t. Instead, I was quiet. Honestly, I was concerned about the chance that my perception was wrong and someone would disagree with me. Perhaps I would get some unwanted attention. I was afraid of what might happen if someone disagreed with me. It was fear, and fear is not a virtue.

Your Voice

You have perspective. You have opinions. You have a voice. And you have a choice of when to speak, when to be quiet, and when to listen. Your thoughts matter, and they should not be silenced. But again, it’s your choice of how you use this voice, and there are consequences for the words you speak.

Your words are so powerful that they will kill or give life, and the talkative person will reap the consequences. Proverbs 18:21 TPT

I have decided that social media possesses no value for me personally, so I will instead focus on those around me, the ones I do life with: my family, my friends, my coworkers, etc.

Community

It’s probably worth investing real energy into researching and putting together a dedicated post, but I want to at least mention how important community is in our lives. This is the people around us. Those we do life with. Those you have influence with. You can have real, heartfelt debates with people face-to-face. Not yelling into the void of the Internet where everyone feels safe behind their keyboards. In person, having discussions with respect and love is a life-giving activity even when you do not agree. It helps us understand the perspective and opinions of those with differing views. This is important. We should be able to and even celebrate disagreement and more generally different points of view without villainizing and labeling people. It’s how we learn from one another. It’s a way of loving one another.

A Call to Action

What are we to do? I can’t tell you that. I decided to leave social media, because it serves no purpose or value in my life. I do not have a large following, and at this time I do not have any notable influence online. My influence is in my community, and I believe that is the best place for me to make investments. Your situation is different, and I would implore you to really consider the “why” of your presence online, and if it’s right for you then give it all you got! When it comes to these services online, I do believe something needs to change. The reality is that these companies are more likely to “feel” the affect of people migrating to other services than resigning en masse. Healthy competition; free market. Either way, make sure you know why you are doing what you are doing and do it (in love).

An Aside About “A Problem”

At the time, I didn’t have a great understanding of how tech companies were able to get away with censorship, and perhaps I still don’t. It seems to all come down to the so-called “Section 230”.

Section 230 is a section of Title 47 of the United States Code enacted as part of the United States Communications Decency Act, that generally provides immunity for website platforms with respect to third-party content. Wikipedia

That “immunity” seems not-good, but I’m no lawyer, so I won’t try to explain or pick it apart. However, it does call attention again to the power of certain companies. While they may not be held legally liable for their users’ content, they may themselves act like “the law” and act in unison to bring another company all the way down, e.g. Parler. My best guess is they explained the removal of this app by saying that “it violated our standards”. So they are able to hold their “citizens” liable for its users’ content, but their own not so much because they happen to own their infrastructure. Interesting. Is that fair? Is that OK for services so fundamental as social media have become? What if AT&T were to decide to cut off tower access to Boost Mobile, because some Boost customers were using their phones in a certain way?

Keep in Touch

I probably won’t be back on any of the social media sites any time soon, so if you’d like to keep in touch you can send me an email at hello@iamvery.com or better yet let’s see one another in person somewhere. ❤️

JS Meetup: A Not Scary Introduction to Lambda Calculus

Wed, 31 Jul 2019 00:00:00 -0500

Lambda calculus is a really interesting way of expressing computation with nothing more than functions of one argument.

Huge shout out to Anjana Vakill which this is based on.

You can find the source and other documents that made up this talk as a Gist.

This talk was given at Florence JavaScript Engineers. It was a small, open group so it ran a little long, but hopefully it’s interesting!

Feature Tours

Wed, 14 Nov 2018 00:00:00 -0600

You write tests that serve many different purposes. On one end of the spectrum, there are “unit tests” which isolate small units of behavior in your code to drive out a well-factored design. At the other extreme there are “feature” or “acceptance” tests that allow you to automate the use of a system as a user of it. These tests are great for specifying the system behavior of a feature. However, you sometimes still choose to isolate each use case of a feature in its own example. That’s where feature tours come in.

A feature tour is an acceptance test that “tours” an entire feature in a single example. First question: Why? There are probably many reasons one could conjure up, but here are a few to consider.

As a user…

Tests at this level are supposed to exercise the system as a user of it. Therefore, any direct database access or other “code level” effects of these tests are technically cheating, because a user cannot do them. You sometimes fall to this temptation so that you can “set up the world” in order to run an example. However, it’s true that in production the only way for the system to get into the states that you’re producing manually is by its use. In this way, your tests are more realistic and less prone to errors in the margins of the behavior being tested.

Coupling

Another problem with writing code to set up acceptance-level examples is that everything you’re writing is in some way coupled to the underlying implementation. Therefore, you will often see this features begin to fail when seemingly unimportant implementation changes are made to the system. This might be categorized as what TestDouble calls a “NOOOPE” test.

Speed

As a final observation, I would like to mention that this style of testing may lead to a faster test suite. It’s true, these style of tests can be very slow. In the context of web, they often involve some sort of browser automation that just takes time to setup and teardown. Therefore, the fewer times you have to do this the better off you are.

Feature Tours

The proposal is that we write such tests as tours of the feature being exercised. For example, if you’re building some basic CRUD functionality in a web app, the test script might look like this:

RSpec.describe 'Post management' do
  it 'supports creating, viewing, editing, and deleting' do
    visit '/'

    click_on 'Add Post'
    fill_in 'Title', with: 'An Post'
    fill_in 'Body', with: 'An post body.'
    click_on 'Create Post'

    expect(page).to have_content('Post created.')
    expect(page).to have_content('An Post')
    expect(page).to have_content('An post body.')

    visit '/'
    click_on 'An Post'

    click_on 'Edit'
    fill_in 'Body', with: 'Once upon a time, there was a post.'
    click_on 'Save Post'

    expect(page).to have_content('Post updated.')
    expect(page).to have_content('Once upon a time, there was a post.')

    click_on 'Delete'
    expect(page).to have_content('Post deleted.')
    expect(page).not_to have_content('An Post')

    visit '/'
    expect(page).not_to have_content('An Post')
  end
end

If you’re like me, this is a bit hard to understand at a glance. As such, I like to extract methods to really emphasize what is in the tour. It’s important to recognize that this is just a code organization change and does not affect the run. Everything still happens sequentially.

RSpec.describe 'Post management' do
  it 'supports creating, viewing, editing, and deleting' do
    add_post('An Post', 'An post body.')
    see_post_created('An Post', 'An post body.')

    edit_post('Once upon a time, there was a post.')
    see_post_updated('An Post', 'Once upon a time, there was a post.')

    delete_post('An Post')
    see_post_deleted('An Post')
  end

  def add_post(title, body)
    visit '/'
    click_on title
    fill_in 'Title', with: title
    fill_in 'Body', with: body
    click_on 'Create Post'
  end

  def edit_post(body)
    visit '/'
    click_on title
    click_on 'Edit'
    fill_in 'Body', with: body
    click_on 'Save Post'
  end

  def delete_post(title)
    visit '/'
    click_on title
    click_on 'Delete'
  end

  def see_post_created(title, body)
    expect(page).to have_content('Post created.')
    see_post(title, body)
  end

  def see_post_updated(title, body)
    expect(page).to have_content('Post updated.')
    see_post(title, body)
  end

  def see_post_deleted(title)
    expect(page).to have_content('Post deleted.')
    expect(page).not_to have_content(title)
    visit '/'
    expect(page).not_to have_content(title)
  end

  def see_post(title, body)
    expect(page).to have_content(title)
    expect(page).to have_content(body)
  end
end

You may have noticed some interesting things about this approach. First, the order of the steps in the tour is very important. For example, you can’t very well see a post until it exists. So for a CRUD feature, very often your tour will end up in the namesake’s order: create, read, update, delete.

But most importantly this tour is entirely agnostic of the implementation details of the system. Its only dependencies are the text and links on the page. It’s content focused. This is also useful when it comes to making visual changes to an app that should not affect behavior.

Summary

While there are pros and cons on both sides of this approach, the truth is it’s often very difficult to maintain these ideals. I believe the real benefit is a strong emphasis on closely considering any implementation coupling that you are introducing to an acceptance test. Such coupling will lead to brittleness and churn in the example, limiting its value over time and frustrating developers.

TEDx: Remotely Productive

Wed, 10 Oct 2018 00:00:00 -0500

What a blast it was to talk about a subject that is so important to me: remote work! There’s no doubt that it’s changed my life for the better. You can do it too!

This talk was given at TEDx Wilson Park.

OSCON: Building Elixir Phoenix

Fri, 10 Aug 2018 00:00:00 -0500

Honored to have been given the opportunity to speak again at OSCON in 2017! It was a really fun talk to put together, where I live code a small subset of the behavior of the Elixir Phoenix web application framework. You can find the code on GitLab.

Code BEAM SF: Elixir in Elixir

Thu, 15 Mar 2018 00:00:00 -0500

Honored to have been given the opportunity to speak at Code BEAM SF 2018! Hit the basics of metaprogramming in Elixir. You may also want to check out the post Getting Started with Metaprogramming in Elixir.

Effective Testing with RSpec 3

Tue, 07 Nov 2017 00:00:00 -0600

If you know me, you know I have opinions about testing software. I’ve been writing software for over ten years now. The single most important skill that I have picked up is writing automated tests. It helps make our work more predictable and increases confidence to make changes. Heck, it’s even fun! If you haven’t used tests to drive a feature, check out my workshop from RailsConf.

Cool, so I love testing. So you can imagine my excitement when Myron Marston asked me to have a look at his new book, Effective Testing with RSpec 3. At 600+ (iPad) pages, this is a book packed with information. In a way it has multiple personalities, but they’ll all help you write better software.

The Philosopher

Part one of the book is about establishing why you should write tests and use RSpec. It answers great philosophical questions like:

Why are my tests so slow?
Are these tests worth their weight?
How can I make progress without failure distracting me?

The book goes into just the right amount of detail to address these things and more. You’re left feeling empowered to get started. I can say as someone that is relatively well-experience with RSpec that I still learned a lot. In a lot of ways, it was like I was reading pages out of my own experience. My kneck is sore from nodding. The writing style and progression just enhances your experience as a reader. Read it. You’ll learn. 💪

The Teacher

Part two is an extended, guided tutorial. I must say this was one of the most surprising and exciting parts of the book. For a long time, I’ve maintained that we do a really bad job teaching software testing as it usually doesn’t extend beyond expect(1+1).to eq(2). With this part of the book, you get a real-world example of building feature with tests. Actually not all that different from my workshop.

Now let me say, experienced testers may not agree with the details of this part of the book. I certainly found myself yelling at paper (erm, iPad glass) at times. But you know what? Software engineers will never agree on the precise details of programming computer’s brains. So set those opinions aside and appreciate the fact that Myron and Ian went to great lengths to provide a real example for folks getting started. Thank you! The community appreciates it. And it sets the stage for interesting conversations about tradeoffs and decision making. 👏

The Librarian

Part three through the end, the Librarian. This is a big, friggin’ reference. RSpec is shamelessly chocked full of features. All in the name of expressive, self-documenting specs.

With great numbers of features, comes great need for reference. — Uncle Sam, probably

RSpec has been pretty stable for awhile, so I imagine this reference will remain valuable for years. If you take the time to read the latter parts of this book, you. will. learn. something. It doesn’t matter who you are or how much experience you have. I’m pretty sure Myron and Ian learned of RSpec features by writing it. Don’t miss the matcher cheat sheet at the end! 🙌

The End

In summary, this is certainly a recommended book for Ruby programmers. Read with an open mind, the first half of the book is useful for all programmers. Testing is such an important part of a software developer’s practice. Do it. Read this book. Read other books. Write tests. ❤️

Integrated Testing with React Native, Part 2: Minimize Coupling

Fri, 29 Sep 2017 05:00:00 -0500

Originally featured on the Big Nerd Ranch Blog.

In the last post, I promised to tell you how breadth-first object traversal came into play testing React Native apps. Today is the day!

As it turns out, unit testing React Native code is really no different than testing any other JavaScript, especially with stateless, functional components. However, unit testing can only get you so far. Inevitably you need to confirm code works in integration. Unfortunately the options we have tend to feel a little heavy-handed with snapspot testing and computer-driven UI tests. Snapshot tests are coupled very tightly the entire structure of a rendered component and thus tend to be brittle. UI tests are difficult to set up and run terribly slow.

Another option is using a tool like Enzyme to make assertions about the VDOM output by the renderer. Unfortunately React Native only works with shallow rendering. It would be great have something resembling full-dom rendering for React Native!

What Is In a DOM?

Enzyme, Jest, and the like use React’s test renderer to produce an in-memory, rendered DOM as a deeplying nested, often recursive JavaScript object tree. One such tree might resemble this:

{
  type: 'View',
  props: [Object],
  children: [
    { type: 'Text', props: [Object], children: ['Just content.'] },
  ]
}

Thankfully, as we found out in the last post, such a data structure is a breeze to traverse!

The Tests

Take for example a component that has loading and error states. When data is available it displays each bit as an item in a list. Start by outlining your test cases:

When data is loading, I see the message “Loading”.
When an error occurs, I see the error message.
When data is loaded, I see each item’s title on screen.

Using visit from the last post, translate these cases into tests:

import React from 'react'
import renderer from 'react-test-renderer'

import Widgets from './widgets'
import { visit } from './visit'

it('displays message when data is loading', () => {
  let data = { loading: true }
  let component = renderer.create(<Widgets data={data} />)
  let tree = component.toJSON()

  expect(content(tree)).toContain('Loading')
})

it('displays message when an error occurs', () => {
  let data = { error: { message: 'It broke.' } }
  let component = renderer.create(<Widgets data={data} />)
  let tree = component.toJSON()

  expect(content(tree)).toContain('It broke.')
})

it('displays item titles when data is loaded', () => {
  let data = { loading: false, items: [{ title: 'first'}, { title: 'second' }] }
  let component = renderer.create(<Widgets data={data} />)
  let tree = component.toJSON()

  let text = content(tree)
  expect(text).toContain('first')
  expect(text).toContain('second')
})

function content(tree) {
  let each = visit(tree)
  let content = []
  for (let node of nodes) {
    if (node && node.type === 'Text' && node.children) {
      content.push(node.children.join())
    }
  }
  return content.join()
}

These tests are written to be very loosely coupled to the structure of the component. All that matters is the tested content is seen in the component. This is done by looking for all Text nodes and testing that the expected content is contained within them.

The Component

To make these tests pass, you can write a relatively simple component.

import React from 'react'
import { Text } from 'react-native'

let Widgets = ({ data: { loading, error, items } }) => {
  if (loading) {
    return <Text>Loading...</Text>
  }

  if (error) {
    return <Text>{error.message}</Text>
  }

  return (
    <Text>{items.map(i => i.title).join()}</Text>
  )
}

export default Widgets

This component is simple if not naive. However, from the tests’ perspective it doesn’t really matter how it’s built so long as the little bits of text are seen. For example, this same component could be completely re-written in a functional style:

import React from 'react'
import { Text } from 'react-native'
import { branch, compose, renderComponent } from 'recompose'

let Loading = () =>
  <Text>Loading...</Text>

let WithLoader = branch(
  ({ data: { loading } }) => loading,
  renderComponent(Loading),
)

let Error = ({ data: { error } }) =>
  <Text>{error.message}</Text>

let HandleError = branch(
  ({ data: { error } }) => error,
  renderComponent(Error),
)

let Widgets = ({ data: { items } }) =>
  <Text>{items.map(i => i.title).join()}</Text>

let enhance = compose(
  WithLoader,
  HandleError,
)

export default enhance(Widgets)

Which looks exactly the same, like this:

The tests still pass! Let’s take things just a little bit further to really drive home the point. Update the Widgets component to use fancy, scrollable lists from [NativeBase][nativebase].

 import React from 'react'
 import { Text } from 'react-native'
+import { Container, Header, Body, Content, List, ListItem } from 'native-base'
 import { branch, compose, renderComponent } from 'recompose'

 let Loading = () =>
   <Text>Loading...</Text>

 let WithLoader = branch(
   ({ data: { loading } }) => loading,
   renderComponent(Loading),
 )

 let Error = ({ data: { error } }) =>
   <Text>{error.message}</Text>

 let HandleError = branch(
   ({ data: { error } }) => error,
   renderComponent(Error),
 )

 let Widgets = ({ data: { items } }) =>
-  <Text>{items.map(i => i.title).join()}</Text>
+  <Container>
+    <Header>
+      <Body>
+        <Text>Items</Text>
+      </Body>
+    </Header>
+    <Content>
+      <List dataArray={items}
+        renderRow={item =>
+          <ListItem>
+            <Text>{item.title}</Text>
+          </ListItem>
+        }>
+      </List>
+    </Content>
+  </Container>

 let enhance = compose(
   WithLoader,
   HandleError,
 )

 export default enhance(Widgets)

Look how much better it looks!

Not only does it look better, but the tests still pass without any changes! That is because the tests are written with a hyper-focus on content. The tests are sufficiently decoupled from the component structure so tests only fail when behavior is broken!

Wrapping Up

This style of testing is a powerful mechanism for validating content without writing tests that are frustratingly brittle (read: prone to false failures). However, it probably does not replace the role of snapshots which ensure that a stable component does not suffer regressions once it’s in place.

What testing strategies have you developed for React and React Native?

Integrated Testing with React Native, Part 1: Generator Functions

Wed, 06 Sep 2017 10:00:00 -0500

Originally featured on the Big Nerd Ranch Blog.

Love it or hate, JavaScript is everywhere. Recently, I took another step toward assimilation by attending the Big Nerd Ranch Front-end Essentials bootcamp. And… all biases aside, IT WAS GREAT! I began the week with two goals:

How to even modern CSS?
React Native sounds cool, but how to test?

Thankfully, the answer to my first goal was “stop being lazy, Jay. Learn flexbox.” The second part was a little more subtle, and I expanded upon the ideas that I had learned in class once I returned home. Throughout the next few posts on the topic, I’ll explain my findings.

Object Traversal

In my recent experience, getting started with React Native testing is a little rough. There are good tools for snapshot testing and shallow rendering, but I wanted something capable of deep rendering without the tight coupling of a full snapshot. To start, I began digging into the output of React’s test renderer which is used with snapshot testing. As it turns out, the results of test rendering are a deeply-nested, often circular object tree.

The first hurdle in establishing a strategy for integrated component testing with React Native is picking out particular nodes in deeply nested object trees. The below screenshots illustrate this nesting. So for example, you might want to assert that certain text is found somewhere in the hierarchy. If you have any functional programming leanings, you may immediately think of this as a recursive problem, and to be honest, it’s quite natural to reason about the problem recursively.

Recursion is great, but it can be tricky to bail early on the routine if you’re only interested in finding the first matching node. Not to mention the complicated story with tail-call optimization in JavaScript. Modern JavaScript provides a useful tool for solving our traversal problem: Generator Functions.

Take a moment to theorize the usage of such a generator function:

let dom = {
  type: 'div',
  props: {
    className: 'main',
    children: [
      { type: 'h1', props: { children: 'Welcome to React!' } }
    ]
  }
}

let each = visit(dom) // This is your traversal generator!

for (let node of each) {
  console.log(node)
}
// { type: 'div', props: [Object] }
// 'div'
// { className: 'main', children: [Array] }
// 'main'
// [ [Object] ]
// { type: 'h1', props: [Object] }
// 'hi'
// { children: 'Welcome to React!' }
// 'Welcome to React!'

Since the return value of generators conform to the iterable protocol, they can be used with the for..of construct! So how should the visit() function be implemented?

Writing `visit()`

Here’s your generator function signature. Don’t forget the asterisk!

function* visit(obj) {
  //
}

The data structures encountered in React Native are often very deeply nested (and sometimes circular), so with that foresight it makes sense to implement visit() as a breadth-first search. To avoid recursion stack limits in JavaScript, revert back to good-ole looping. Initialize a queue with the subject of your search and loop until you’re all out of nodes:

function* visit(obj) {
  let queue = [obj], next
  while(queue.length > 0) {
    next = queue.shift()
    yield next
    // think of the children!
  }
}

Hurray, you have visited the first object, but the algorithm is incomplete. How can you visit each of its children?

To answer this question, consider the types of children that must also be visited: arrays and objects. Take those into account:

function* visit(obj) {
  let queue = [obj], next
  while(queue.length > 0) {
    next = queue.shift()
    yield next
    if (Array.isArray(next)) {
      queue.push(...next)
    } else if(next instanceof Object) {
      queue.push(...Object.values(next))
    }
  }
}

So, if the next value in queue is an Array, add all its values to the array. Otherwise, if it’s any sort of object, add all of its enumerable properties to the queue. The spread operator (...) is particularly handy for this use.

That’s it! You can now visit each node in any object graph. However, there are a couple more things to consider.

API

For general use cases, it may not be desirable to require folks to deal with visit() directly. Instead, you might want to expose a more functional interface such as each():

var obj = {
  type: 'div'
  props: {}
}
each(obj, console.log)
// { type: 'div', props: {} }
// 'div'
// {}

Providing such an interface is very straight-forward:

function each(obj, fn) {
  let visitor = visit(obj)
  for (let node of visitor) {
    fn(node)
  }
}

More interestingly, we can build on visit() to provide other common functions on collections. Take find() for example, which returns the first match without visiting the entire tree:

function find(obj, match) {
  let each = visit(obj)
  for (let node of each) {
    if (match(node)) {
      return node
    }
  }
}

find({ foo: { bar: 'it me' } }, n => n.bar === 'it me')
// { bar: 'it me' }

You can imagine even more functions implemented in this way. Give map(), count(), and select() a try on your own!

Circular References

There is one more edge case to consider. Circular references are trivially easy to create in JavaScript, and such an object would result in infinite looping with our current implementation of visit():

var obj = {}
obj.self = obj
each(obj, console.log) // THIS IS THE LOOP THAT NEVER ENDS

The issue is easily addressed by ensuring that the exact same node is never visited twice. You can accomplish this by keeping track of which nodes have been seen:

 function* visit(obj) {
-  let queue = [obj], next
+  let queue = [obj], next, seen = new Set()
   while(queue.length > 0) {
     next = queue.shift()
+    if (seen.has(next)) { continue }
+    seen.add(next)
     yield next
     if (Array.isArray(next)) {
       queue.push(...next)
     } else if(next instanceof Object) {
       queue.push(...Object.values(next))
     }
   }
 }

Hurray, no more infinite loops!

But… Testing?

Theory and generalizations are fun and all, but how can we use this practically? I promised to relate this to React Native testing. You’ll have to look out for the next post to see how this all comes together. Stay tuned!

OSCON: A Less Complex Web with Ratchet and Jank

Tue, 13 Jun 2017 00:00:00 -0500

Honored to have been given the opportunity to speak at OSCON 2017! This is a talk about the complexity of web development and some ideas to avoid it. You can find the slides on Speakerdeck.

Composing Elixir Functions

Fri, 16 Dec 2016 00:00:00 -0600

Function composition is a technique used to build complex functions out of simpler ones. Elixir does not provide a mechanism for composing two functions into a new function. Let’s play with that a little and see what can be done.

An Example

Say using Elixir you want a function that appends an element to a list. An efficient way to do this is by first reversing the list, then prepending the element, and finally reversing the list again.

Kick things off by manually implementing append in terms of reversal and prepending:

iex> append = fn list, item ->
  list = Enum.reverse(list)
  list = [item|list]
  Enum.reverse(list)
end
#Function<...>
iex> append.([1,2,3], 4)
[1, 2, 3, 4]

This certainly gets the job done, but perhaps it could be even more to the point. The main problem is the implementation shifts the focus from the operations to state management. The list variable is introduced and repeatedly referenced (5 times!) during the execution of the function. As Josh points out in his decomposition blog, Elixir provides a mechanism for composing function applications with its pipe |> operator. Refactor it with pipes:

iex> prepend = &[&2|&1]
#Function<...>
iex> append = fn list, item ->
  list
  |> Enum.reverse
  |> prepend.(item)
  |> Enum.reverse
end
#Function<...>
iex> append.([1,2,3], 4)
[1, 2, 3, 4]

That does seem quite a bit better (idiomatic, even)! You no longer repeatly refer to list, and the implementation is more clearly composed of prepend/2 between calls to reverse/1. Even so, the state management is still present in the form of arguments. Is there an implementation that’s even more clearly composed of the operations? What if you could compose the existing functions together into a new append function?

Elixir does not provide such an operation, but imagine a custom infix operator, <|>, for composing functions:

iex> append = reverse <|> prepend <|> reverse
#Function<...>

Such an append function would, in effect, capture the expression reverse(prepend(reverse(list), item)), requiring the arguments list and item in that order.

Compose

To arrive at the final implementation, start by implementing a compose/2 function using recursion. First define the base case:

defmodule Compose do
  def compose(f, arg) do
    f.(arg)
  end
end

This base case effectively applies the arg to the function f. For example:

iex> double = fn n -> n*2 end
#Function<...>
iex> Compose.compose(double, 4)
8

Next add an implementation of compose/2 that recurses when the second argument is a function:

defmodule Compose do
  def compose(f, g) when is_function(g) do
    fn arg -> compose(f, g.(arg)) end
  end

  def compose(f, arg) do
    f.(arg)
  end
end

This version of compose/2 returns a function that applies its argument to g and then composes the result with f. However, at this point the implementation works only to compose functions that accept a single argument, i.e. having an arity of 1:

iex> reverse_sort = Compose.compose(&Enum.reverse/1, &Enum.sort/1)
#Function<...>
iex> reverse_sort.([3,1,2])
[3, 2, 1]

It does not work for functions requiring many arguments (N-arity):

iex> reverse_prepend = Compose.compose(&[&2|&1], &Enum.reverse/1)
#Function<...>
iex> reverse_prepend.([1,2,3])
** (BadArityError)

The error happens, because compose/2 only ever applies one argument, i.e. .(arg). Elixir is strict about the arity of functions. For compose/2 to work with N-arity functions, you need some way to apply a variable number of arguments.

Arguments

A solution to this problem is changing how N-artiy functions are applied. Since there is no way to anticipate how many arguments will be needed, you can instead rearrange the function to support multiple single-argument applications until all have been provided. This is a common functional programming technique known as currying.

Currying converts a function of arity N into a function of 1-arity that when applied N times produces the result. Consider this example of manual currying with nested functions:

iex> add = fn a -> fn b -> a+b end end
#Function<...>
iex> add_one = add.(1)
#Function<...>
iex> add_one.(2)
3

The function add is defined to return another function. The result of applying the value 1 to add returns a function that accepts the second argument for the addition. This idea of applying only part of what a function needs to return a result is called partial application. The partial application of add with 1 is a function that “adds one”. Once all the arguments have been applied, the result is returned:

iex> add.(2)
#Function<...> # a function that "adds 2"
iex> add.(2).(3)
5

Notably, this mechanism is not built into Elixir, but there are packages that add the behavior as well as a great post on currying in Elixir. For the remainder of this post, it’s assumed you have a module Curry that includes a function curry/1 such that you can:

iex> add = Curry.curry(fn a,b -> a+b end)
#Function<...>
iex> add.(2).(5)
7

Finishing `compose/2`

As you have learned, currying is a solution to your variable argument problem. It also happens to fit really well into the recursion that is already set up in compose/2. Update the implementation to curry both functions passed in:

 defmodule Compose do
+  import Curry
+
   def compose(f, g) when is_function(g) do
-    fn arg -> compose(f, g.(arg)) end
+    fn arg -> compose(curry(f), curry(g).(arg)) end
   end

   def compose(f, arg) do
     f.(arg)
   end
 end

It might be surprising to realize this is the only change needed to complete the implemetnation! The recursive definition of compose/2 applies arguments one at a time to the composed function until a result is found, and then then applies that result to the outer function in the base case. See if it fixed your arity error:

iex> reverse_prepend = compose(&[&2|&1], &Enum.reverse/1)
#Function<...>
iex> reverse_prepend.([1,2,3]).(4)
[4, 3, 2, 1]

Nice! Notice that each successive argument is a partial application to the underlying curried functions. The really cool thing is that the order of the arguments called on reverse_prepend matches the order of respective arguments to each composed function; the list first, then the prepended item.

Custom Operator

For convenience, complete your implementation of Compose with a custom infix composition operator, <|>:

defmodule Compose do
  import Curry
  def f <|> g, do: compose(f, g)
  ...
end

That’s it! Now by importing Compose, functions may be composed together with <|>:

iex> import Compose
Compose
iex> square = fn n -> n*n end
#Function<...>
iex> fourth = square <|> square
#Function<...>
iex> fourth.(2)
16

`append`

Tie up this experiment by returning to the original task. Recall, you want to define a function append in terms of reverse and prepend. The implementation with function composition is now purely expressed as operations:

iex> reverse = &Enum.reverse/1
#Function<...>
iex> prepend = &[&2|&1]
#Function<...>
iex> append = reverse <|> prepend <|> reverse
#Function<...>
iex> append.([1,2,3]).(4)
[1, 2, 3, 4]

Mathy Conclusion

One important note is that the Elixir implementation demonstrated is not pure function composition in the mathematical sense. Function composition requires that function signatures match exactly in order to be compatible for composition. No such restrictions exist in this implementation. In fact it displays the interesting property of trickling arguments down in order until each composed function is fully applied. Elixir is a dynamically typed language, and as such it allows a lot of flexibility in how functions are defined and applied to. Have fun!

On Elixir's Deprecation of Barewords

Mon, 05 Dec 2016 00:00:00 -0600

I subscribe to the Elixir language core mailing list as a means of keeping my finger on the pulse of the language. A post of particular interest has recently fired up the discussion. Elixir 1.4 introduces a warning for function invocation without parenthesis. This style, commonly referred to as “barewords” makes variables and zero-arity function invocations look syntactically identical.

self # Q: Is it a local variable or a function with no arguments? A: It Depends.™

To date, I have never written a line of Elixir that violates my strict loyalty to barewords style, but today I’m fine with this change. Given a little reflection and the well-stated reasons for the change in the above-reference post, I’ll go along with the ride. Allow me to explain.

Functions and Values

Elixir is a functional programming language. As such Elixir maintains a strong distinction between functions and values (data). Values do not have functionality. You cannot invoke a method on a value as you might in an object-centric language like Ruby. If you wish to perform some work on a value, it is passed as a parameter to a function.

The barewords style that I have grown to love acts to subtly obscure this distinction. You must look around in context to determine whether a bareword is simply a reference to a variable or a function invocation that may very well cost computation. As much as you may want a bareword function to read as a value, a value it is not. At the simplest it’s a function that returns a literal at which point, you might want to check out module attributes or macros.

Barewords also introduce some ambiguity that can lead to real confusion. For example, there was recently a subtle bug in the elixirkoans.io project that would have been caught with this warning. Having forgotten to name a parameter in the function, things went on “working” because the zero-arity function Kernel.node/0 was automatically included.

It feels a little offputting to me that a function (zero-arity) might be masquerading as a value (bareword). The small parenthetical tax paid to reinforce the function/value distinction seems worth it.

Change is Hard

It’s always hard to lose something you love, but these struggles are inevitable. I am very thankful for José and team for being willing to make the hard decisions to keep the language lean and spry. Keep up the fine works, folks.

Here’s to you fig leaf operator (). 🍻 Keep us from baring all.

h/t @CodingItWrong for the “fig leaf” metaphor

ElixirConf: Elixir in Elixir

Wed, 28 Sep 2016 00:00:00 -0500

Honored to have been given the opportunity to speak at ElixirConf 2016! Hit the basics of metaprogramming in Elixir. You may also want to check out the post Getting Started with Metaprogramming in Elixir.

Catching Strong Params Problems Early

Thu, 15 Sep 2016 05:00:53 -0500

TL;DR: Use the ActionController::Parameters.action_on_unpermitted_parameters configuration to control the behavior of Rails’ strong parameters.

Ruby on Rails developers, here’s a scenario:

You’re adding an attribute to a model in your application. You’ve done it all right:

Written an acceptance test for your feature
Created a migration to update the database schema
Added new form input for the data in your view

However, when you run the test suite, the test fails. But how can that be? You’re an experienced Rails developer. This is basic stuff!

The test output isn’t very helpful either:

Expected page to contain [new attribute data], but it didn’t.

After double-checking your test, the last resort is firing up the application and trying it out in the browser yourself. Confirmed, the form is set up correctly, elements are named as they should be. You fill it out and submit it. It all works, but why isn’t the model being updated?! Time passes, you’ve debugged here and pry’d there. Then it suddenly hits you. The new parameter was not permitted with strong params!

Has this ever tripped you up? It gets me all the time, and I teach this stuff. If only there was a way to have Rails raise an error when an unexpected parameter is encountered out by strong params… Actually, there totally is!

Configuration

Rails provides a small bit of configuration to control the behavior of strong params for unexpected parameters. ActionController::Parameters.action_on_unpermitted_parameters. The default behavior is to :log the occurrence and move along. However, another option is to :raise an error. Perfect.

Take a moment to experiment with this option.

irb> ActionController::Parameters.new(name: "Jay", age: 29).permit(:name).to_h
=> {"name"=>"Jay"}
irb> ActionController::Parameters.action_on_unpermitted_parameters = :raise
=> :raise
irb> ActionController::Parameters.new(name: "Jay", age: 29).permit(:name).to_h
ActionController::UnpermittedParameters: found unpermitted parameter: age

That is exactly the behavior you want from your app! Create a configuration file for strong params.

# config/initializers/strong_params.rb
if Rails.env.test?
  ActionController::Parameters.action_on_unpermitted_parameters = :raise
end

With that configuration loaded, Rails will now raise an exception in your test environment any time an unpermitted parameter is encountered.

A timely error reminds you that you must permit parameters, rather than wasting time realizing that parameters are being quietly stripped from the request. For more information see the documentation.

Back to Work

Does this tip resonate with you? Do you have an alternative method of avoiding this common pitfall while building apps? Let us know what you think!

Testing External Dependencies with Fakes

Wed, 27 Jul 2016 00:00:00 -0500

Communication with remote services is often an inevitable part of writing interesting software. Difficult problems (e.g., address validation) are easily solved by integrating with third-party solutions.

Unfortunately, relying on remote services complicates the goal of writing automated tests for your application. Without decoupling your code from these external factors, your test suite grows continually slower each time an example communicates with the outside. Additionally, services may or may not be available during the run, causing test failures unrelated to your code.

An effective strategy to address this problem is to draw a line at the boundary between your code and the service. At that boundary, replace the external integration with a stand-in, a fake.

A Testing Strategy

To get familiar with this approach, consider an example. Say you want to add a feature to your application that fetches page titles using the Open Graph protocol. After some research, you settle on a small library that gets the job done.

OpenGraph.new("https://bignerdranch.com").title
# time passes as request is made and response is processed...
# => "Big Nerd Ranch - App Development, Training, & Programming Guides"

Wrap It

Justin Searls recently wrote an article that clarifies a phrase you often see: “Don’t mock what you don’t own”. As he points out, the purpose of that phrase is to encourage test writers to wrap external dependencies in an application-owned adapter.

The benefit is two-part:

It establishes a consistent interface for accessing the behavior you need.
It serves “as a specification of what you’re using in that dependency.”

Go ahead and introduce a trivial adapter for your Open Graph integration.

class WebPage
  def initialize(url)
    @open_graph = OpenGraph.new(url)
  end

  def title
    open_graph.title
  end

  private

  attr_reader :open_graph
end

This step may seem unnecessary, but there is value in establishing a consistent interface in your application. The benefit is quickly felt if you later decide to use a different Open Graph library, or the initialization of the library you’re using is awkward. With your adapter’s interface established, you’re ready to create a test fake.

Note: It is important to write tests that verify your adapter correctly integrates with the library it wraps. However, those tests feel very off-subject for this post. I’ve written a pull request to demonstrate how one might test the adapter.

Fake It

To avoid the pitfalls of external influence on your tests, implement a fake that is a duck type for WebPage. The fake should be simple, but as Martin Fowler says, it must have a working implementation to support dependent code.

Consider this implementation that returns a URL’s hostname as its title:

require "uri"

class FakeWebPage
  attr_reader :url

  def initialize(url)
    @url = url
  end

  def title
    host
  end

  private

  def host
    uri.host
  end

  def uri
    URI(url)
  end
end

This stand-in provides an alternative strategy for determining the page title without having to make a web request. Try it out for yourself, and see that it’s good enough.

FakeWebPage.new("http://some_web_page.com")
# => "some_web_page.com"

It seems to get the job done. Now you can configure your application to use the test fake when running tests.

Here’s a pull request that shows a similar implementation in the context of an app.

Confidence in the Implementation

No real integration happens in test. How can you be sure it really works? That’s a genuine concern.

The library code (the bit performing external communication) must itself have integration tests written that verify its own external behavior. When using a third-party library, this is often a responsibility that maintainers take seriously. If you have written the integration (or you don’t trust theirs), test the integration directly in isolation. You might use a tool like VCR to record and play back web requests for tests.

For critical integrations, you may even want to allow external communication by an isolated portion of your tests that is only run in certain environments. This provides the absolute confidence that the real integration works. However, realize that it comes at the cost of speed and reliability (e.g. external service may go down).

Responsibility

Fundamentally, the struggle of how to test external integrations is one of responsibility. Is it really your application code that should bear the task of maintaining this integration? No. That burden falls to library code. It might be that the library is born out of your application’s codebase (see Rails’ ./lib directory). But the library itself is not concerned with the domain of your application, e.g. selling widgets. Conversely, the application should not be concerned with the domain of the library, e.g. fetching and parsing Open Graph metadata. These distinctions become easier to see when library code is extracted as a dependency from your application.

You might say that an application should be built solely out of domain-specific code, libraries and configuration.

Summary

Create thin wrappers to establish consistent, app-owned interfaces for faking.
Replace these adapters with fakes to avoid external dependencies in your tests.
Enjoy speedy tests that are unaffected by remote services you do not control.

When to Parallel Map

Thu, 09 Jun 2016 00:00:00 -0500

In his book, Programming Elixir, Dave Thomas referrs to the parallel map function as the “hello world of Erlang”. It is a fun problem to solve! The premise is relatively simple, the operation performed on each element is done in separate processes. This allows the work to be done in parallel on the collection. If you’re interested in an exmaple, check out my friend Nathan Long’s post

So why would you want to map over a collection in parallel? The answer is usually “it’s FASSSST!” Yes, but when? The bottleneck that parallel map addresses is the serial nature of the traditional map operation. Each element is evaluated in serial and the operation is applied. If the operation is slow, then the map operation can be significantly sped up by running them in parallel. However, as with all optimizations there is a tax. In the case of parallel map there are two taxes:

the overhead of creating and communicating with processes
two iterations through the list (one to start processes, one to get results)

Therefore…

Use parallel if:

sum(cost of operations) > cost of iteration + cost of processes

Otherwise, use regular map.

Put more succinctly, parallel map is a good fit if the operation being performed on each element is slow.

Here’s a benchmark in Elixir.

And the results:

● master ~/Code/OSS/parallel » mix run samples/maps.exs
Benchmarking quick pmap...
Benchmarking quick map...

Name                          ips            average        deviation      median
quick map                     23093.24       43.30μs        (±19.05%)      41.00μs
quick pmap                    140.88         7098.46μs      (±16.30%)      6926.00μs

Comparison:
quick map                     23093.24
quick pmap                    140.88          - 163.93x slower

Benchmarking slow pmap...
Benchmarking slow map...

Name                          ips            average        deviation      median
slow pmap                     78.93          12668.78μs     (±9.53%)       12592.50μs
slow map                      0.50           2000475.00μs   (±0.02%)       2000475.00μs

Comparison:
slow pmap                     78.93
slow map                      0.50            - 157.91x slower

Slow operation, parallel map wins. Fast operation, regular map wins.

Visual Guide to Folding

Wed, 08 Jun 2016 00:00:00 -0500

You know folding. You fold things everyday, clothes, paper, stacks of cash.

fold: bend something over itself so that one part of it covers another

— Dictionary.app

The act of folding is combining two parts into one. This precisely explains fold in functional programming. You fold a collection to iteratively combine its elements into a new value. Don’t be confused, fold goes by many different names in various programming languages, object-oriented and functional alike.

accumulate(e.g. C++)
aggregate (e.g. C#)
inject/reduce (e.g. Ruby)

A full listing of folding functions in various languages may be seen on Wikipedia.

Despite the name, these functions all have the same basic behavior. They combine a collection by repeatedly applying some operation to its contents.

A Visual

Paper was mentioned as something you might fold. In fact it makes a practical example of programmatic folding. Consider a piece of paper containing a collection of numbers.

To combine the numbers on the paper, you might fold each pair together from the left.

Likewise, you might also fold them together from the right.

For now, consider folding from the left. In order to combine each pair of values, you must provide an operation to perform at each fold. For example, to find the sum of some numbers you might fold the collection of numbers with addition.

With the addition operation inserted between each pair, you can fold the collection applying the operation at each step.

Addition is a well-known operation that most folks are familiar with, but the operation used may be arbitrarily complex as long as it has two operands and returns a value compatible with the next fold. It might even be a function itself. Folding from the left with addition might resemble the following Elixir code.

# Elixir
add = fn a, b -> a + b end
foldl([1,2,3], 0, add)

An anonymous addition function is defined and bound to the variable add. Then the fold is performed on the list of numbers [1,2,3] with the initial value 0.

Now consider a different operation. Instead of combining the collection together into a single number, the collection may be combined into a new collection. This is often referred to as “mapping”, i.e. mapping each value in the collection to a new value. The operation used by such a fold might look like this Ruby code.

# Ruby
double_shovel = ->(list, number) { list << number*2 }
foldl([1,2,3], [], double_shovel)
# => [2,4,6]

Again, a lambda (i.e. anonymous function) is defined that doubles the numbers and appends it to the array. The fold is performed with that function given an empty array ([]) as its initial value.

At each fold, the operation is applied to the last operation’s result and the next element in the collection. An initial value is provided to serve both as a starting point and as a default given an empty collection.

A Naive (Ruby) Implementation

Armed with your understanding of fold, it’s time to implement a fold_left function. Start with a method written in Ruby.

def naive_foldl(list, result, operation)
  list.each do |item|
    result = operation.(result, item)
  end
  result
end

addition = ->(a,b){ a+b }
naive_foldl(addition, 0, [1,2,3])
# => 6

Source

If you’re not used to recursion, this iteration-based implementation might be easier to grok. Starting with the second argument (result) as our initial value, the operation is iteratively applied to the result of each operation and the next element in the array. Once the entire array has been traversed, the final result is returned.

Ruby already provides a method like this in its Enumerable module, reduce.

# Ruby
[1,2,3].reduce(0) do |a,b|
  a+b
end
# => 6

Recursion

The previous implementation is considered naive, because it requires an intermediate variable result which is repeatedly assigned to throughout the run. Do not confuse naive with wrong. The solution works, but may not be the most elegant. More commonly fold is implemented using recursion. Some might argue that it is even more readable that way. Consider the following implementation of fold left written in Elixir using recursion.

def foldl([], result, _operation), do: result
def foldl([head|tail], initial, operation) do
  foldl(tail, operation.(initial, head), operation)
end

add = fn a, b -> a + b end
foldl([1,2,3], 0, add)
# => 6

Source

This implementation recursively calls foldl by applying the operation to each resulting value and the next element (“head”) of the list. In fact, similar to Ruby’s stdlib Elixir offers a very similar function by the name reduce in it’s Enum module.

Enum.reduce([1,2,3], 0, fn a, b -> a + b end)
# => 6

Does that help?

Hopefully you have found the explanation as demystifying as I have. Despite the inherent complexity of recursion and higher-order functions, the fold operation does not have to be difficult to grok. Did you find this helpful? Let me know! Also check out my other post, Folding Elixir for a little more in-depth explanation of the Elixir implementation.

Jay Hayes / iamvery.com

Best Hayes Ahead

Better LiveView Tests

Background

Test Helpers

Half-Truth

The Truth

The Lie

Refocusing

A Problem

Your Voice

Community

A Call to Action

An Aside About “A Problem”

Keep in Touch

JS Meetup: A Not Scary Introduction to Lambda Calculus

Feature Tours

As a user…

Coupling

Speed

Feature Tours

Summary

TEDx: Remotely Productive

OSCON: Building Elixir Phoenix

Code BEAM SF: Elixir in Elixir

Effective Testing with RSpec 3

The Philosopher

The Teacher

The Librarian

The End

Integrated Testing with React Native, Part 2: Minimize Coupling

What Is In a DOM?

The Tests

The Component

Wrapping Up

Integrated Testing with React Native, Part 1: Generator Functions

Object Traversal

Writing visit()

API

Circular References

But… Testing?

OSCON: A Less Complex Web with Ratchet and Jank

Composing Elixir Functions

An Example

Compose

Arguments

Finishing compose/2

Custom Operator

append

Mathy Conclusion

On Elixir's Deprecation of Barewords

Functions and Values

Change is Hard

ElixirConf: Elixir in Elixir

Catching Strong Params Problems Early

Configuration

Back to Work

Testing External Dependencies with Fakes

A Testing Strategy

Wrap It

Fake It

Confidence in the Implementation

Responsibility

Summary

When to Parallel Map

Visual Guide to Folding

A Visual

A Naive (Ruby) Implementation

Recursion

Does that help?

Writing `visit()`

Finishing `compose/2`

`append`