The importance of more difficult tests (TDD) and a mansplaining asshat

Today, I was made aware of the importance of writing, (and maybe failing) more difficult tests. I have to say, the circumstances in which I was coding were not ideal. I joined the process workshop for the first time, and I was paired with somebody that seemed quite nice when we just chatted, but when it came to coding, he constantly talked over me, ignored my helping hand, and mansplained to me, plus took ten minutes extra on his code, that left me with only 20 minutes as opposed to 30. That obviously is going to happen more often, as tech is still a man’s world, and I am hoping to improve the way I deal with this, but today, it got me stressed out.

The code I was writing was quite simple and consisted of 3 difficulties. The first one was to return whether or not an input year was a leap year. The following was given to me:

• All years divisible by 400 ARE leap years (e.g. 2000 was a leap year)
• All years divisible by 100 but not by 400 are NOT leap years (e.g. 1700, 1800 and 1900 were not leap years)
• All years divisible by 4 and not by 100 ARE leap years (e.g. 2004, 2008 and 2012 were leap-years)
• All years not divisible by 4 are NOT leap years (e.g. 2009, 2010 and 2011 were not leap years)
I hear you think, uh Emma? Isn’t it just every year that is divisible by 4? And you will be correct. However. I started doing the following:

require ‘leap_year’

describe LeapYear do
describe ‘#leap_year?’ do
it { respond_to(:leap_year?).with(1).argument }
it ‘should know if it is a leap year’ do
expect(subject.leap_year?(2000)).to eq true

class LeapYear

def leap_year?(arg)
arg % 400 == 0

This passed my test, because I only chose the year 2000, and did not do any further testing. Mansplain then told me to take another look at the info they provided. So I copied all their info into code and checked if all of those would return true. Which they did. UGH. It then took me WAY to long to figure out how simple it could be, but with mansplain breathing down my neck, I was in flight mode. Anyways, I managed to change my code into the correct one:

def leap_year?(arg)
arg % 4 == 0

and continued to the next question.
If mansplain had not pointed it out before, I would have figured out my first test was wrong by now, as I would now have to return an array of years between the first and second given argument, that would be a leap year.

describe ‘#leap_array’ do
it { respond_to(:leap_array).with(2).arguments }
it ‘should return all years that are leap years’ do
expect(subject.leap_array(2000, 2008)).to eq [2000, 2004, 2008]

I wanted to use the first argument to find out which ones were leap-years

def leap_array(arg1, arg2)
arg_array = (arg1..arg2).to_a
array = []
arg_array.each { |year| leap_year?(year) ? array << year : nil }
return array

I would have gone wrong here, but I figured it out in time. And as mansplain tried to point out just as we were being returned to our main meeting, this can be a long ass array. Do I care? Not really.

Lastly, I wanted to return the leap year closest to a given year

describe ‘#nearest_leap_year’ do
it { respond_to :nearest_leap_year }
it ‘should return the nearest leap year’ do
expect(subject.nearest_leap_year(2003)).to eq 2004

def nearest_leap_year(arg4)
year = 4 — (arg4 % 4)
( arg4 += year ) % 4 == 0 ? arg4 : arg4 -= year

Now I require a hot shower and a good meal and celebrate women’s day(!!!!) to get over how annoying this guy was.

My journey through Makers academy