Lambda School - Week 14: Get Ready For The Big Test!

I've always hated tests. There, I said it! Ever since first grade, I thought tests simply got in the way of learning. Ms. Johnson disagreed and gave me an F.

Well, it seems like tests have followed me to Lambda School, years after I finished - what I thought would be my - final exam. I'd hoped to avoid it, but it seems tests and test-driven development were on the menu this week! Joy of joys.

After five days of classes, I am once again fully aware of why I hated test-driven development in the first place, but also why it's so damn useful. There's been lot of nagging, cursing, keyboard-throwing (or at least imagined), and a whole bunch of coding. In the end though, I absolute aced the test!

Here's what went down.

If you happen to have lived under a rock over the past couple of months, let me quickly introduce you to Lambda School. Lambda School offers online programs in software development, UX design, data science, iOS and Android mobile development. The best part? It has no up-front costs!

The curriculum is 9 months long with full-time enrollment. This used to be 30 weeks, but has recently been extended. Instead of paying tuition and having to take out a second mortgage just to pay tuition, Lambda School uses Income-Share Agreements (ISAs). With it, students pay a percentage of their monthly income after they’re employed. If you don't get a job, you don't pay anything. Second, you only start paying if you're making more than a certain amount per year. Depending on where you're based, different percentages and pay-off plans exist. Americans pay 17% for 2 years after graduation, while Europeans pay 10% for 4 years.

In the US, If you make less than $50k after graduation, you don't have to pay ‘em anything. Also, you will never, under any circumstance, pay back more than $30k. (Note: you'd have to be making more than $88,000 per year to achieve that) If you happen to make less than that, you simply pay less. After two years, you're off the hook What's more, if you don't find a job and spend all that time making less than $50k, the ISA lapses after a couple of years.

Recently, Lambda has introduced a living stipend program. It'll pay students $2000 per month to cover monthly bills while they focus fully on their studies. In return, Lambda asks for 10% of their income over 5 years. The payoff is capped at $50,000.

So This Is Pass/Fail?

Ahh tests, my old nemesis. It's like flossing your teeth every day. Everyone says they do, but no one really does.

When working as a developer on a large project, you have to make sure your code works. Hell, you even need to do that when you're building a tiny app in a single hour. If your code doesn't work or it produces errors, it as good as useless. So, how do you make sure your code works perfectly? That's right, you test the shit out of it!

Imagine your manager walks up to you, saying a piece of code you produced is completely broken. How convincing do you think it'd be if you told him you'd tested everything with copious amounts of console.log statement? You'd be laughed out of the building in minutes.

So to test our work and have verifiable proof that it actually works, we write tests. Quality Assurance is an enormously important aspect of the development process. It's often its own department. They will dive deep into your code, try to uncover edge-cases, break things by passing invalid information, beat your code up with a baseball bat (okay, maybe not that) and in general try to figure out if your code is watertight under any circumstance.

QA is kind of like that one babysitter you had when you were a kid; always running after you to clean up your shit and make sure you didn't kill yourself on accident. It's not the most glamorous job, but damn if it isn't important. And if you don't have a fancy-schmancy QA department, you're just going to have to write those tests yourself. Don't forget to bring your baseball bat.

Unit tests in a nutshell
Unit tests in a nutshell

Frankly, I always hated having to write tests as part of my code. Sure, I appreciated its power and loved how foolproof it made our projects. I still hated every second of it, though. On and off, we experimented with Test-Driven Development (TDD) at WhiteWash Development. Essentially you're flipping the script. First, you write a test that checks if a particular function returns a desired outcome. Only then do you actually start to write the function, slowly inching your way closer to passing the test.

By writing your tests first, you can quickly create a list of edge-cases or exceptions where you code should behave in a non-traditional way. So you write tests for them and then integrate them into your functionality one by one. If you try doing it the normal way (by writing code first, testing afterwards), you'll focus on satisfying the base-case and will often forget about some of the more insidious edge-cases.

By using TDD, our code was a lot cleaner and way easier to maintain. It just took so damn long to code!

I Forgot to Study For The Test

Lambda School gave us a single week to get up and running with tests and Test-Driven Development. Ouch.

Over the course of four days, we pretty much revisited the entire curriculum and learned how to implement tests on everything. Simple JavaScript functions? We tested them. React Components? For sure. Back-end endpoints? You guessed it. The only thing we didn't cover in great depth was end-to-end testing, which was a bit of a bummer.

Frankly, I think Lambda messed up with this approach. By cramming all of it in a single week, you're not giving students time to get used to a new programming paradigm. Information overload was a common complaint this week. Even more so than usual.

Ideally, Lambda School would've insisted on Test-Driven development right from the get-go. If unit tests had been covered as soon as we started with the fundamentals of JavaScript, writing tests would've been second-nature and students would've been taught good development practices straight off the bat.

Our instructor was an absolute champ this week and went out of his way to go over the material again and again. As many times as needed for students to wrap their heads around testing.

This happens to the best of us…
This happens to the best of us…

By the end of the week, people were a bit torn on whether they liked test-driven development or not. From what I could tell, most people were a little ambivalent to it. They definitely appreciated the use case, but wouldn't necessarily implement them for every single feature of a web app. I mostly agree. For small side-projects you'll only work on by yourself, there's little need. As soon as other people will work on your codebase in the future though, you might want to start writing some tests. (Or risk angry co-workers)

Tools OfThe Trade

This week, we covered the following:

  • An introduction to tests and test-driven development. Why we use them why test-driven development has become the gold-standard in the world of software development
  • The difference between unit tests, integration testing, snapshot testing, and system testing.
  • Some of the most common testing frameworks like Jest, Enzyme, Supertest, and React Testing Library.
  • Brief overview of end-to-end testing to whet our appetite. I played around with Cypress for a bit afterwards.
  • In what cases it becomes superfluous to use tests.
  • Massive amounts of exercises to ingrain the habit of writing tests. Seriously, we must've written over a hundred unit tests in about four days.

This week, a lot of students were dealing with tooling issues. Not too surprising, considering that we were getting introduced to a bunch of different packages and testing frameworks. There's always bound to be someone who has a machine that doesn't want to cooperate.

In terms of coding itself people caught on pretty quickly. If you're well-versed in writing business logic, writing tests themselves shouldn't be too difficult. You just have to get used to the syntax and peculiarities of the particular testing framework you're using.

I will say that I've gotten a greater appreciation for Test-Driven Development as a result of this week. Ever since I quit the web agency, I hadn't really bothered with test-driven development. It took too much time and I couldn't be bothered. Now, I might opt to write some tests every now and then when working on my side-projects.

Who would've thought.

All Tests Passed!

This week was one of the easier and more relaxing weeks in my Lambda School career. As you might have learned by now, I never was the biggest fan of test-driven development. Having used them previously, I knew why they could be really valuable. I just absolutely hated having to write them myself.

It really is like flossing your teeth. You don't really want to do it and it takes a bit of effort, but it is oh-so-valuable over the long-term. By not writing tests (and flossing), you're prioritizing short-term comfort over long-term viability (and dental hygiene)

It requires a bit of a shift in mindset.

I tend to be pretty paranoid during my development. I have dozens of console.log() and debugger statements scattered throughout my code to make sure things work exactly the way I want them to. I purposely try to break my code and adapt on the fly. Testing is simply a better way to go about it.

Having a structured way of ensuring you're not fooling yourself is invaluable. And according to Richard Feynman, you're the easiest person to fool. Don't fool yourself.

Make sure to floss, kids!

Sign Up For Friday Favorites!

Join the 500+ people who receive my Friday Favorites newsletter in their inbox every week. It's a mash-up of the most interesting links, books, and ideas I came across that week, as well as my latest articles and book notes. If you're curious and looking for high-quality information, you should definitely join.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.