When To Unit, E2E, And Integration Test

Recorded live on twitch, GET IN

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

[lleytonmorris]

I have never seen prime read an article with as little reading error, I think he really mentally vibes with this kind of writing

[sburton]

While you wouldn't use a 1TB file for testing you might still process files that large in production, in which case the implementation that tries to load the entire file into memory before passing it to the function that does the work is not going to work well, so you'll probably want to process the data as a stream. But that still doesn't mean you need to open the file within that function, it can take a generic stream object, so in production you can pass a file-stream that reads from your 1TB file and for testing you can pass a memory-stream that just reads some test data from memory.

[MrBreakstuff]

Never test until you know what the program output should be. If you know what the output should be, you can write a test. You should write that test as soon as you know the output, no sooner, no later. Don't add more than one test at a time. If a test you didn't just add is failing, it's a regression. Keep your testing simple or it will summon the shadow demon.

[dqvodyg]

your description of seperating data sources and the actual code under test (passing the file content) did really help me write better code and have more fun writing tests.

[rafaelbordoni]

The 1TB file guy works at Tom's startup.

[fishfpv]

The last place I worked had flakey tests in all of their services. Plus tests were not run in CI even though CI existed. Everyone looked at me like I was the crazy person when I made a large effort to debug some of the failing tests. Even better most of the tests were unit tests with huge mocks 🙃. Let's just say I got out of there very fast

[AlgoristHQ]

People are missing out on the true power of TDD and BDD. You are supposed to spend time thinking about and writing the tests. This guides how your code is written in a much cleaner way than simply writing the code. Of course, write the tests from the view point of the business value being added and not from the viewpoint of your state design pattern.

[victornascimento]

I find it funny how we came from "we hate system modelling" to "oh no i dont know how to unit test before developing because we dont have system modelling"
(its not a critique, I really find it funny because it happens to me too)
Also this guy's way of writing is so fun lol and hell yeah that mocking problem \m/

[Rin-qjzt]

i usually make a test whenever i notice a spot where a certain level of complexity passes through. it's great intuition that saved me a lot of time. the more serious tests come later when the code feels more solid like mentioned in the video.

[asherrfacee]

I decreased my reliance on integration tests and write mostly unit tests. Increased coverage, decreased test time, eliminated flakes tests because only integration tests introduce flakeyness.
Writing a million mocks that’s necessary to make integration tests is so painful and can take more time than it took to write the feature I’m in trying to test. I just use integration tests for main scenarios and handle all my edge case testing in unit tests.
Focusing more on unit tests also has the effect of encouraging more procedural programming rather than OOP, as you’ll stop overloading classes with private methods and start moving logic into static library functions that can be unit tested.

[BenRangel]

Using mostly e2e and never have problems with Grugs kind of mystery breaking tests.

Many years ago the team were into unit testing but we found those rarely saved us. The problems were often in steps between the units.

Worked with TDD fans for a while, it can work without too much messing around if you just assert html containing text. But stopped doing it, I could never really feel at ease with thinking a failing test was fine and normal.

The place I work at now as a paid part-time intern, the first real task given to me when switching to the backend was to write mock tests to increase branch coverage for the whole repo to 80%. The only tests we have now are some sort of integration/system test based on a few hundred megabyte large files. Soo, two paid interns are now tasked with writing tests with mocking for the whole codebase. It's the most painful experience of my life.

[luismiranda]

11:05 are there more resources to get primes point on this one? i don't think i fully got his example

[AlgoristHQ]

My experience with test first has changed how I write code. My code is more reliable and my tests are easy to change when business requirements change. The secret? I focus on business value and not on implementation. Also, I use dockerized databases for my testing so I never have to mock repos. It isn’t difficult but it seems that way to those who haven’t done it before.

Edit: fixed a typo

Added note, I’m not saying that I’m more talented than others. My team and I have figured out how to use BDD to guide our development. We believe in BDD and TLD. Everything is just a tool to help you write code. Use what works for you.

[TheChillBison]

That comment about not mocking was gold to me, as right before you said that I was thinking, "But how can you not mock? I don't want to use the real thing in tests." And yet there was a third way: factor out the dependency so that to write a unit test for that function amounts to testing a third party tool, so you wouldn't, and then you have the complex function that just needs a simpler input that's easy to construct in a test.

[akillersquirrel]

3:47 grug use unit test, cage complexity spirit demon

[youngKOkid]

Disagree about mocking effects (e.g. file system access, database access, http requests). Testing effectful code is the whole motivation for mocking. Instead of actually performing side effects in your unit tests, you tell the test what you expect to receive from the external system, and then assert that your program returns the expected result. While it's a best practice to extract effects from otherwise pure code and test the pure functions independently, it's also important to test the operations that perform effects (e.g. read X from DB => perform HTTP request with Y=> store response Z in DB).

[djl]

good! :D @2:07...calling out Dave Farley -- glad someone is doing it! and in such a humorous, balanced and accurate manner! ...soooo good! really enjoying this!

[casraf]

Every article should be written in grug

[scaylos]

I like TDD for Go w/ Testify, personally. Often I'm using "golden" tests as my starting point though because I can define my expected inputs and outputs. Then, I write more verbose tests on bits that I'm not as confident in. I find that I always end up wasting time tracking down bugs when I get lazy and skip unit tests to try to get it done