DEV Community: Will Lawrence

Using Capybara to test responsive code

Will Lawrence — Fri, 11 Nov 2022 20:41:21 +0000

As more users opt for mobile browsing, responsive design becomes more important — even for applications that are primarily used on a desktop. Responsive design is a key consideration for Aha! Ideas because it's convenient to answer polls and submit ideas using mobile devices. Usually the application behavior between mobile and desktop are the same, just rearranged on the page. But what happens when application behavior is different between devices with different-sized screens? Automated tests are necessary to ensure these different screen behaviors perform as expected in their environments.

Engineering at Aha! focuses on using and improving the Capybara test framework. We have added many helpers and additional functionality to make working with Capybara easy. Testing at mobile widths is another chance to improve our testing tooling. Here is the incremental approach that we used to add mobile testing helpers.

First pass

Below, we have an example test.

context "mobile user" do
  scenario "user logs in on mobile" do
    # These labels are specific to mobile widths
    expect(page).to have_content("First name")
    expect(page).to have_content("Last name")
  end
end

This test will fail because we aren't resizing to mobile width, so our name labels won't appear. Let's fix that.

context "mobile user" do
  # resize to mobile width
  before { page.driver.browser.manage.window.resize_to(375, 764) }

  scenario "user logs in on mobile" do
    # These labels are specific to mobile widths
    expect(page).to have_content("First name")
    expect(page).to have_content("Last name")
  end
end

This is an acceptable first pass. Our page is indeed resized for mobile testing. However, it presents three problems:

It doesn't tell us why we are resizing. The test has that information but it would not be clear out of the test.
This code isn't particularly reusable because it requires some insight into how Capybara works.
The test window remains resized for all subsequent tests. This is a subtle problem that will lead to unexpected and intermittent test failures.

Using a helper

Let's see how we can fix those three problems. Below is a helper we can use to resize for mobile testing.

# in spec/support/capybara_helpers.rb
def with_mobile_width
  page.driver.browser.manage.window.resize_to(375, 764) # resize to mobile
  yield # run the test
  page.driver.browser.manage.window.resize_to(1920, 1080) # resize back to default
end

And then in our test:

context "mobile user" do
  scenario "user logs in on mobile" do
    with_mobile_width do
       # These labels are specific to mobile widths
       expect(page).to have_content("First name")
       expect(page).to have_content("Last name")
    end
  end
end

This solution works better. It can be reused, it tells us why we are resizing, and it won't interfere with other tests. But there is still room for improvement.

We are adding another layering of nesting to the test. If we continue to use it in other places, then we are going to have some deeply nested tests. There is another way we can get this functionality without using this helper.

Updating our configuration

I want to be able to drop a :mobile_width in our test declaration. This resolves our three problems and won't clutter the tests. Below is an update to our configuration.

# in spec/support/capybara.rb
rspec_config.before(:each) do |example|
  browser = Capybara.current_session.driver.browser

  # if we have :mobile in test, resize. Otherwise go to default.
  if example.metadata.key?(:mobile_width)
    browser.manage.window.resize_to(375, 764)
  else
    browser.manage.window.resize_to(1920, 1080)
  end
end

Here we are using the before(:each) hook. This does exactly what it says on the box. Before each test runs, hook into it and perform an action. In this case, we are checking to see if the test has a :mobile_width key. If it does, run at a mobile width. If it does not, run at the standard width. The test looks a lot cleaner.

context "mobile user", :mobile_width do
  scenario "user logs in on mobile" do
    # These labels are specific to mobile widths
    expect(page).to have_content("First name")
    expect(page).to have_content("Last name")
  end
end

All the tests in the mobile user context are now going to run at that width. We have addressed the original three issues. This is reusable, it explains what we are doing to the test, and the mobile width won't leak into other tests. We also don't need to add another layer of testing to our code like we did by adding the with_mobile_width helper, so the tests remain tidy and sustainable.

Aha! is happy, healthy, and hiring. Join us!

This feature took a lot of tinkering and guidance from other engineers. Without such a knowledgeable and helpful team, I would not have arrived at this clean solution. If you want to build lovable software with this talented and growing team, apply to an open role.

Math and Ruby: Generating Fibonacci Numbers

Will Lawrence — Sun, 31 Oct 2021 19:04:48 +0000

Introduction

This is going to be a little interlude between the the Project Euler problems because the next problem has to do with Fibonacci numbers!

The Fibonacci sequence is generated with two initial integers, usually 0 and 1, and then adding those two terms to create the next term in the sequence. The sequence continues to infinity by adding the two previous terms in the sequence. They come up in the Project Euler problems pretty frequently because they are mathematically interesting and present some performance issues when generating them.

This post is going to talk about a three ways to generate Fibonacci numbers, and what the different tradeoffs

Method 1: Recursion

Because of the way the Fibonacci sequence is defined, it lends itself to being generated with a recursive function. Lets take a look:

def nth_term_recursive(n)
    return n if (0..1).include?(n)

    (nth_term_recursive(n - 1) + nth_term_recursive(n - 2))
end

We have our base cases, 0 and 1, the first two terms of the sequence. After that, we keep calling the method until we get to the base case, and then we roll up to the actual value of the term in the sequence that we wanted. This works, and it's a classic.

However, as we get more into the project Euler problems, we are going to run into some issues with performance. This method runs in O(2^n) time, which is fine for small values, but is really slow when it comes to large values, say the 10,000th term in the sequence.

Method 2: Iteration

Using iteration and holding the values in memory, we can speed up the method. Let's take a look.

def nth_term(n)
  fibonacci_terms = { 0 => 0, 1 => 1 }
  return fibonacci_terms[n] if fibonacci_terms.keys.include?(n)

  while fibonacci_terms.count <= n
    next_term = fibonacci_terms[fibonacci_terms.count - 1] + fibonacci_terms[fibonacci_terms.count - 2]
    next_key = fibonacci_terms.count

    fibonacci_terms.merge!(next_key => next_term)
  end

  fibonacci_terms[n]
end

This method will yield the same results. We start with our base case, and then generate a hash where the key is the index of the term in the sequence, and the value is the value of the term. By using a hash, we can store the terms of the sequence that are needed to generate the term that we want. This gives us a method that operates in O(n) time, which is a big improvement. If we want, we could even memoize the results so that we could find terms that were already calculated.

Method 3: Binet's Formula

There is actually a way to directly calculate the terms in the Fibonacci sequence, but there is a problem. It can only be used in limited cases (at least on a computer). We can use Binet's Formula. However, because of the rounding errors that occur when we take square roots, this method breaks down. Let's take a look:

def binets_formula
  puts "Binet's Formula is not accurate for n > 70" if n > 70

  sqrt5 = Math.sqrt(5)

  ((((1 + sqrt5)**n) - ((1 - sqrt5)**n)) / ((2**n) * sqrt5)).round
end

We can see that I output a string when we are looking at the terms greater than 70. Lets compare what happen when we use Binet's Formula against our iterative method for the 70th and 71st terms of the Fibonacci sequence.

irb(main):001:0> Fibonacci.nth_term(70)
=> 190392490709135
irb(main):002:0> Fibonacci.binets_formula(70)
=> 190392490709135
irb(main):003:0> Fibonacci.nth_term(71)
=> 308061521170129
irb(main):004:0> Fibonacci.binets_formula(71)
Binet's Formula is not accurate for n > 70
=> 308061521170130

As you can see, we start getting drift between the results, and the result from Binet's formula is no longer accurate.
However, for the terms that are accurate, we can get them in constant time, so that's cool.

Conclusion

For problems that use the Fibonacci sequence, I will likely use the iterative approach since that has a good balance between speed and accuracy, but something tells me that there are even more complex ways to get large Fibonacci numbers in a faster time than O(n).

You can checkout the source code for this post on my Github.

Math and Ruby: Project Euler Problem 1

Will Lawrence — Sun, 24 Oct 2021 18:37:45 +0000

Introduction

This is the first post that I am writing in a while, and it's mostly because I wanted to start working through all the problems on Project Euler. I wanted to do this for a few reasons. First, they are hard problems, so they are good way to practice. Second, they let me keep my math skills sharp. Third, They ley me practice my ruby.

This first problem is fun, but we don't get a chance to look at clever mathematical approaches. But we do get to see some of the methods that we have in ruby.

Problem Statement

The Following Problem was taken from Project Euler:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.
Find the sum of all the multiples of 3 or 5 below 1000.

This is a great problem because it takes a classic problem (FizzBuzz) and adds an extra layer too it. More importantly, it has a single integer result as opposed to an array of integers and strings.

Breaking it down.

This problem is basically saying that we need to do a few things. First, we need to find all the numbers from 1-999 that are multiples of 3 or 5. Then, we need to sum all those numbers together. This is a pretty straightforward problem. Let's see what we can do.

Attempt One: Iterative Approach

I remember the first time I was asked to look at FizzBuzz, and the sort of approach that I would take when I first started coding. It would have looked something like this.

n = 1
sum = 0

while n < 1000
    if n % 3 == 0 || n % 5 == 0
        sum += n
    end

    n += 1
end

return sum

This is a pretty short method, but it certainly has room to improves. When we run this code, we get the following result: 233168. Spoilers, this is the correct answer. But we can get it in a much more ruby way.

Attempt Two: Declarative Approach

So the iterative method gets us the correct answer, but can we get there with less code? Yes. If take a more declarative approach and take advantage of ruby's array methods, we can write the following method.

[*1...1000].select! { |n| (n % 3).zero? || (n % 5).zero? }.sum

So this is doing a lot so let's break it down. First we are using * and a range to create all the values that we need to look at, 1-999. Then we are creating new array by selecting all the value that are multiples of 3 or 5 from the original array. Finally, we find the sum of the newly created array to get our result. The result of this method is 233168, which is the same as the above method.

Comparing Methods

Is either of these approaches better? From a stylistic and readability perspective, the second method is probably better, but you need to know how splats, ranges, and array methods work.

But what about performance? When we benchmark the iterative approach, we get the result in 0.039 milliseconds When we benchmark the declarative approach, we get our result in 0.106 milliseconds. So the iterative approach is a lot quicker. I would need to dive into the implementation details to see why, but my guess is that the declarative method is probably generating a lot of overhead, while the iterative method is just performing the calculations we need.

What is the fastest way we could achieve this result?
What is the most readable way we could get this result?
And finally, what is the best way?

You can checkout the source on my GitHub.

Maslow's Hierarchy of Needs In An Application

Will Lawrence — Mon, 20 Jan 2020 00:50:00 +0000

Introduction

First, thanks for reading! This is my first post here on Dev.

If you aren’t familiar with Malsow’s Hierarch of Needs here's a brief explanation of the theory. There's a hierarchy of what a person needs, and they need to have all the things on one of the tiers before they can start fulfilling the needs on the next tier. Without having your basic physical needs satisfied, you can't have your higher-order needs fulfilled.

What do you need in application?

Let’s take that and apply it to applications. Let’s assume that you can only have one of the following before you can add another:

Performance
Documentation
Tests
Readability
Maintainability
Functionality
Security
Accessibility

I think that I would probably go in the following order:

Functionality--the app should work, right?
Readability--hopefully a person can read the code.
Maintainability--the code should be easy to maintain. This falls in line with readability, but has more to do with organization.
Security--the application should be secure and follow basic security principles.
Accessibility--the application should be accessible to ALL users.
Documentation--the code, as well as any user documentation, exists and is valid.
Tests--the application has automated testing. This is my passion and it makes me so sad that this falls so low.
Performance--the application is performant.

Your Turn

How would you rank them?

What would you add?

What is missing?

How did you decide your order?