When To Unit, E2E, And Integration Test

  Рет қаралды 104,865

ThePrimeTime

ThePrimeTime

Күн бұрын

Пікірлер: 163
@lleytonmorris6305
@lleytonmorris6305 Жыл бұрын
I have never seen prime read an article with as little reading error, I think he really mentally vibes with this kind of writing
@JorgetePanete
@JorgetePanete 11 ай бұрын
I think it's because it forces anyone reading this to slow down and read twice
@ak-loz
@ak-loz 11 ай бұрын
I truly vibed here as well!
@IQof2
@IQof2 9 ай бұрын
This observation is important to Prime lore
@atharva__shukla
@atharva__shukla 5 ай бұрын
100%
@sburton84
@sburton84 Жыл бұрын
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.
@spetz911
@spetz911 Жыл бұрын
I was about to write the same exact comment :)
@Zzznmop
@Zzznmop Жыл бұрын
Testing the wrong things or testing for now
@bluecup25
@bluecup25 Жыл бұрын
Yeah, but in that case Stream would be an abstraction, FileStream the real implementation and MemoryStream the mock implementation. It's just that in this case they already are provided to you by the environment. But replace this with some remote service, external device reader etc. and that's when you have to create mocks.
@joejoesoft
@joejoesoft Жыл бұрын
... and then you've a test case that never fails a read. You still need cases that exercises all paths. So, you'd need a separate function wrapping any file call that can fail. Bam, you're now mocking io fails and 1 function is now six functions. Sending file contents is a ticking bomb. You pass the buck for the error conditions, but you've a function that's blind when the world around you changes (as Carmack puts it). You need something that's testing the size of that input and warning when it goes beyond expected usage. That's logging now instead of unit testing. The buck has been passed again to the production side.
@Blaisem
@Blaisem Жыл бұрын
Me see grub, me put like
@ivandimitrov4410
@ivandimitrov4410 Жыл бұрын
I prefer grub2
@martinschmelzle4864
@martinschmelzle4864 8 ай бұрын
Me see grub, me boot Linux
@rafaelbordoni516
@rafaelbordoni516 Жыл бұрын
The 1TB file guy works at Tom's startup.
@sutirk
@sutirk Жыл бұрын
Tom is a genius, his git repo has only one json of 1kb and 1terabyte git history
@MikeZadik
@MikeZadik Жыл бұрын
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.
@MrBreakstuff
@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.
@akillersquirrel5880
@akillersquirrel5880 Жыл бұрын
3:47 grug use unit test, cage complexity spirit demon
@fishfpv9916
@fishfpv9916 Жыл бұрын
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
@CallousCoder
@CallousCoder Жыл бұрын
A unit test with a mock is most often useless. As you are making assumptions as to how that foreign device or system work. And you’re developing something that’s relatively complex that you can’t test. The only mocks that are reliable are those that the manufacturer made and maintains. I’ve had a situation where a customer used mocks and simulators and their production release crashes. Because they assumed (wrongly) that the send() would always send the whole packet. Which is the case on a localhost and fast Ethernet but it doesn’t over the real internet. So the first chairs they wanted to book at the airline force the system 😂 One look at the code and I laughed so hard, “TDD is. It replacement for sloppy ignorant developers”. Even without any automated tests this would not have happened in my case, because I always check every results for production code. I fixed it without even running the useless test, I just booked a ticket and canceled it again. “That’s is the only real test! End to end baby! Now automate that and forget those useless unit tests” 😂 We did this for energy- and medical systems which need to be certified every time you change something. So we never trusted on unit test only integration and E2E. The units you’ll test anyway by hand when you develop. And the when you write proper code, you’ll don’t have to change them again. Because you never change an individual lego brick. You’ll make a new one but never change the old when it does what it was specified to do.
@biomorphic
@biomorphic Жыл бұрын
In the last place where I worked as CTO, I found we had over 1000 tests, but for each run a number of tests was failing, randomly. It took a long time to fix the broken tests, established the causes, and eliminate the useless ones, to have 100% pass. Broken tests, especially random failing tests, are useless, they make the entire test suite a waste. Also most of unit tests are a waste. People who do write tons of unit tests are noobs following trends, like the ones using TDD.
@CallousCoder
@CallousCoder Жыл бұрын
@@biomorphic I like having you as a CTO! I agree that 99% of the unit tests are utterly useless. You test those visually when you write them and when your units are extremely small you never need to touch them again. Any discrepancies don’t show up in the unit tests anyways because a strict unit test doesn’t have connection to external resources and that’s where the most of the exceptions come from. And that argument that when an integration or a e2e test fails that you don’t know what causes it, shows two potentials issues 1) your changes are too big and you need to commit smaller and more frequently. 2) your code base isn’t properly structured. Because what an engineer does is actually analyze where a cause is. A car mechanic doesn’t run unit tests he runs in modern cars a series of integration tests.But great mechanics just hear it feel the behavior and know what’s wrong or at least where to look. I started my career as an EE and fixed hardware. You don’t even have schematics (akin to source code) and you just had to figure it out. And we did most of the time and that’s stuff we didn’t even design ourselves.
@requizm
@requizm Жыл бұрын
@@biomorphic "most of unit tests are a waste" It really depends on the projects.
@Sammysapphira
@Sammysapphira 7 ай бұрын
​@requizm do you need to write a unit test for passing a string into a function that is typed as an object when typescript or compilation would literally prevent this from happening? I see unit tests like this all the time probably just to push numbers up by creating fake tests that don't actually test anything. College kids are taught to "unit test every singe possible way you can expect a function to fail" and it leads to a lot of nonsense.
@TheChillBison
@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.
@AlgoristHQ
@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.
@Propherex
@Propherex Жыл бұрын
I completely agree with that, I wanted to write it myself.
@josefd8
@josefd8 7 ай бұрын
I also agree with you here, and feel people in the video totally miss the point. TDD is NOT a testing practice, is a sofware development practice where the tests are a byproduct. It helps you to avoid exactly what they are saying in the video is something 'inevitable', which is, coupling the test with the implementation. When you do it and implementation changes, all your tests are inmediatly invalid
@djl3009
@djl3009 Жыл бұрын
Sooooo 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!
@tongobong1
@tongobong1 Жыл бұрын
I urged Dave Farley to stop promoting the mockist unit tests many times and he just don't get it how bad they are. He told me that a huge system he was programming and is full of mocked tests is very successful...
@AlgoristHQ
@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.
@igelineau
@igelineau Жыл бұрын
dockerized databases are a game changer!
@bezi2949
@bezi2949 Жыл бұрын
I would like to know more about this. How do you prepare data in the docker db? Do you insert it via sql on start? Isnt it hard to maintain and understand the test data later?
@bryanbisimotopinas345
@bryanbisimotopinas345 8 ай бұрын
need more details
@AlgoristHQ
@AlgoristHQ 7 ай бұрын
@@bezi2949 sorry that I'm just now getting to this. When you use a tool like spec flow to implement bdd, you get access to something called .feature files. You're allowed to write tests in the gherkin syntax and you can set up quite a bit of seed data in the feature file directly or in a CSV that is imported into one of the steps, given, when, then. The point is that you can just use your base crud functionality to save all of this data. As your test is running. I like to run the tests, seed. The data in the given statements, run the when which is the action step, run the then which is the assert step, and then delete any data that I no longer want to use for future tests.
@AlgoristHQ
@AlgoristHQ 7 ай бұрын
@@bezi2949 One more note, you shouldn't need to understand the data later because it's all about testing now. All testing data is invalid after the tests have run so it should be deleted.
@hld3738
@hld3738 Жыл бұрын
One of my coworkers, the most senior of senior devs, "fixed" a flickering test. His changes broke a bunch of other tests that now randomly fail. He doesn't seem to care, so I take that as I can ignore them aswell.
@lukasmolcic5143
@lukasmolcic5143 Жыл бұрын
just ask him and have a chat about it
@hld3738
@hld3738 Жыл бұрын
@@lukasmolcic5143 The problem is he is basically omnipotent, and trying to talk to him would be more trouble than it's worth. I'm just there for the paycheck at this point until I find a new job.
@Rin-qj7zt
@Rin-qj7zt Жыл бұрын
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.
@casraf
@casraf Жыл бұрын
Every article should be written in grug
@JonathonMcClung
@JonathonMcClung Жыл бұрын
Time to start the Rewrite it in Grug movement
@ma-moomoo
@ma-moomoo Жыл бұрын
@@JonathonMcClungBrb gonna implement gruglang
@TehKarmalizer
@TehKarmalizer Жыл бұрын
I could get on board all three of these ideas.
@victornascimento4246
@victornascimento4246 Жыл бұрын
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/
@bluecup25
@bluecup25 Жыл бұрын
Everyone hates planning ahead before they dig themselves in a hole that basically requires rewriting the whole thing to get out of.
@luismiranda9817
@luismiranda9817 Жыл бұрын
11:05 are there more resources to get primes point on this one? i don't think i fully got his example
@TJ-hs1qm
@TJ-hs1qm 8 ай бұрын
Mixing TDD with FP is my approach, it helps me break down problems into smaller pieces that I can easily wrap my head around. Tests also double up as documentation, like google maps for new team members.
@JohnDoe-bu3qp
@JohnDoe-bu3qp Жыл бұрын
Turns off alerts so we don't have to hear "welcome to Costco, I love you", proceeds to say "welcome to Costco, I love you". 🤔
@BenRangel
@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.
@JorgetePanete
@JorgetePanete 11 ай бұрын
Never in my 2 jobs have we had failing tests across several projects, or any tests whatsoever 😂
@youngKOkid1
@youngKOkid1 Жыл бұрын
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).
@kevinb1594
@kevinb1594 Жыл бұрын
That sounds like a e2e test which by definition should use mocked data unless you're a real cowboy and decide to use production data.
@youngKOkid1
@youngKOkid1 Жыл бұрын
@@kevinb1594 I would use a staging/beta environment for an E2E test. The advantage of this kind of unit test is that you can handle all possible cases. Whereas E2E cases can handle a happy path + a few common failure modes.
@licriss
@licriss Жыл бұрын
+1 on breaking up IO and logic for testability
@TheKlopka
@TheKlopka Жыл бұрын
Im on the build team. Devs hate me, managers love me because i used the iron rod of god where if your PR fails any unit tests, it doesnt get to be in master. Simple as that. Now our unit tests work and no one ignores failing tests
@Ivcota
@Ivcota Жыл бұрын
Why do devs hate you? We shouldn’t want bad code in prod lol
@garveziukas
@garveziukas Жыл бұрын
Because many devs only care about writing code and not good code
@TheKlopka
@TheKlopka Жыл бұрын
@@Ivcota You would be surprised. A lot of devs hate even running their sql before committing it.
@RobertBMenke
@RobertBMenke Жыл бұрын
Grug is a smart grug. Use club to smash like.
@PelFox
@PelFox Жыл бұрын
"if you have to mock you've done something wrong" and "dont like flaky tests".. well how do you do an integration test decoupled from services you don't control? Surprise, you mock them.
@scaylos
@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
@Spirrwell
@Spirrwell Жыл бұрын
There's a certain point where I start to naturally "test" my code to make sure it does what I think it does. You write a little code to make sure it works, and that's that. I usually just throw that code away when I'm done with it. But I think this is the precise moment when unit tests start to make sense. I'm literally already writing them, might as well keep them around. The whole writing tests before you write code thing never really made sense to me though. Unless you have a crystal clear specification for how something should perform, writing tests beforehand seems quite counterproductive.
@aoeu256
@aoeu256 Жыл бұрын
Writing temporary tests while you were running your code is part of REPL/interactive development. You could save some of your interactions to serve as examples, and maybe as tests. Writing your tests beforehand as part of and along with behavioral constraints) is part of example or spec or constraint based coding where you give your specs to the computer and a smart compiler may give you a good implementation, intergration tests and end-to-end tests and unit tests are good to give to chatGPT so that it can program more effectively and serve as good comments/documentation that can be partially run.
@Mister5597
@Mister5597 Жыл бұрын
I think I have grug brain, can't quite understand (8:50) what does Prime mean by bad data/flaky test. Also, thank you Prime for the demo 10:30, really useful for someone that hasn't built things with automated testing and is trying to learn more about it.
@ThePrimeTimeagen
@ThePrimeTimeagen Жыл бұрын
:) ty
@fennecbesixdouze1794
@fennecbesixdouze1794 Жыл бұрын
A flaky test is one which is non-deterministic. You can run it 100 times in a row without changing a single line of code and sometimes it will pass, other times it will fail. This can happen quite a lot: if your tests use randomized test data, or reference the system time, or have async code in them that could have race conditions, or if your test runner runs the tests in a non-deterministic order and you are sharing some data between tests, etc etc. Flakiness can happen with any kind of test: E2E tests, integration tests, or even unit tests.
@danielvaughn4551
@danielvaughn4551 Жыл бұрын
moral of the story - don't reach for the testes until you're fully firm
@StefanvonderKrone
@StefanvonderKrone Жыл бұрын
We have so called time bombs. These tests would run normal all the time, but then out of a sudden they fail because of some datetime things. One test used to fail every day between 0-1pm 🤷‍♂️
@avithedev
@avithedev Жыл бұрын
"Keep It Simple Stupid" 😂😂😂
@josephmbimbi
@josephmbimbi 8 ай бұрын
I think it might still be useful to have one dedicated test to verify your app / tool / whatever doesn't just crash on your 1TB file if that is something your tool is expected to handle, but don't mix that "perf test" with testing functionality. And it is probably streaming data inside, doing some parsing shit, not just holding all of it in memory lol
@HoboManAwesome2001
@HoboManAwesome2001 Жыл бұрын
Grug speaks how prime reads normal english. I'm happy that Prime found a writer that he can read well 😁 (all jokes I love Prime).
@CallousCoder
@CallousCoder Жыл бұрын
I stopped doing unit tests (there are exceptions, but generally don’t see the use of them) because my units are so small it’s just useless. It’s like testing to see if you can stick a key in a lock. Of course that still works after manually testing it the first time - I can pin a lock and cut a key! I am more interested if the engine turns over when I turn the key and that all cylinders are firing aka Integration tests. I don’t need to write a unit test to see a spark on every spark plug. We put coils around the spark plug wires to monitor it always (integration, end to end and in operation tests -- that is useful). I know if I get a pulse when that the spark plug sparks. And then I want to be sure that my truck can still pull the tiles out of the pavement after I tinkered with the engine aka end to end test. I’ll actually put it on a test bench and push it. The only unit tests I make is for business logic where corporate and governmental inconsistencies make weird exceptions in basic knowledge. And you want to test I’d the input triggers the right logic. I have no comparison in the car world for that 😂 But in medical systems you have a lot of exceptions based on sex, weight, age - and a combination of those, those combinations you need to test in a unit test. But we also twat those in E2E test cases. Especially if they could lead to harm or death when done wrong.
@Salantor
@Salantor 9 ай бұрын
"If you have to mock you did something wrong". React components testing would like to have a word.
@LimitedWard
@LimitedWard Жыл бұрын
Not sure what the aversion to mocking is about. Even in the fs example you provided, your file read function would still need try-catches or other branching logic to validate the file was successfully read. And then at that point you need a way to emulate what happens if the file is not found or some other error occurs (hence the need for a mock). Mocking is just a natural extension of dependency injection.
@TheMetadude
@TheMetadude Жыл бұрын
"I'm a tool and I build tools ..." hahahaha
@AScribblingTurtle
@AScribblingTurtle Жыл бұрын
6:54: No failing tests, because no tests exist. But we have a ton of notices, that get triggered per request in various places where "undefined" array indexes, variables and Constants are accessed the wrong way. (Lession for life: "Don't let JS Developers write PHP without supervision") Most of these missing vars and consts are global, meaning, if we would set or define them, there is a chance that all the parts that do the checks correctly would break. But no Client ever would pay us for rewriting and testing half the codebase for all 100 client configurations, so we have to use the "Homer Simpson Solution" instead. Suppress the error output and disable error-logging. (Named after an Episode of the Simpsons where Homer "Fixes" a warning light in his car by putting a sticker over it.) And before anyone says anything. Yes we actually do fix the notices that we come across while doing other work. Our Boss just does not allow us to fix the system outside of tasks that are payed by some Client. (Time and Money are very important to him)
@CodingSync
@CodingSync 9 ай бұрын
It's so satisfying to have all of your initial code failing because it is a bunch of unit tests and the manager asks how's it going.
@neel6
@neel6 Жыл бұрын
post the whole thing as 1 video at this point T_T
@AScribblingTurtle
@AScribblingTurtle Жыл бұрын
Why? This format is much better for appeasing the YT-Algorithm-Gods. A playlist would make more sense.
@neel6
@neel6 Жыл бұрын
@@AScribblingTurtle True, it might be better for the algorithm but when I watched the first video I liked the article he was reading but it stopped in between which was kinda disappointing. Then the second one came and I was like oh nice but again it gets divided into a 3rd one and idk if this is the last one.
@joshuarose20
@joshuarose20 Жыл бұрын
Congrats on 100K!
@michaellatta
@michaellatta 9 ай бұрын
I like this a lot. I agree, only unit test where the algorithm is complex enough to need it. I prefer API testing with API between components. Test each component/layer.
@Nebulorum
@Nebulorum 9 ай бұрын
When Grug use TDD Grug leave club and use metal tools
@me_rinta
@me_rinta Жыл бұрын
I am a little confused about the “you shouldn’t mock” premise Suppose I have an API call and a function that does something with its response somewhere, how can I test that function without mocking the API call? Or did I miss the point completely?
@darrorpsk6148
@darrorpsk6148 Жыл бұрын
Its just like reading the file example. Don't read the api inside the function that also does the business logic. Separate the Read api step, pass the contents to the logic function. You'll have to put these two together somewhere but this way you can test all logic with zero mocking
@kasper_573
@kasper_573 Жыл бұрын
The problem with mocks is that you break one of the most important principles of testing: don't mess around with the implementation details. When you mock, you literally replace/monkeypatch implementation details of your code. You are actively making your test more brittle. And it's just laziness too, because all mocking can be avoided by instead refactoring your code and allowing for better dependency injection, like prime demonstrated.
@bigs2469
@bigs2469 Жыл бұрын
@@kasper_573I agree with the dependency injection approach. However, most JS developers I've encountered prefer just module mocking rather than DI.
@pmatar
@pmatar 10 ай бұрын
@@darrorpsk6148 I still don’t get it, how could I avoid making a real api call in tests without mocking :/
@ilikegeorgiabutiveonlybeen6705
@ilikegeorgiabutiveonlybeen6705 7 ай бұрын
​@@pmatari guess if it mocks its an integration test then and the point is "never mock in unit tests"? i have no idea though
@tongobong1
@tongobong1 Жыл бұрын
What is the difference between unit tests and integration tests?
@-Jason-L
@-Jason-L Жыл бұрын
His definition of "inbetween tests” is still a unit test. Use these as your unit tests, and TDD is easy. More micro level tests are pointless, as these higher level tests will fail. It took me 15 years to begin understanding this.
@zeocamo
@zeocamo Жыл бұрын
10:47 Prime know PureFunctions without knowing what it is called.
@mvargasmoran
@mvargasmoran Жыл бұрын
you didn't forget, yet we heard the "costo" line from you anyway.
@nolatone
@nolatone 8 ай бұрын
Can someone get this guy some more coffee?
@shakibrahman
@shakibrahman Жыл бұрын
young grug love wise grug advice
@steffennilsen2132
@steffennilsen2132 Жыл бұрын
mocking sucks, but you have little options with 3rd party code if it doesnt implement dependency injection (which can also become tedious if its overdone, but it sure beats mocking)
@makowiec2k
@makowiec2k Жыл бұрын
Why the hell would you make a function for a function call?
@wadecodez
@wadecodez Жыл бұрын
I have only used mocking when working with a flaky 3rd party API that required consumers to build controllers, payloads, and issue requests. There were so many points of failure in implementing their code that mocking had to be the only right solution.
@Gaijin101
@Gaijin101 Жыл бұрын
Its so true, the word 'integration test' causes so many sour faces.
@TheThunder005
@TheThunder005 Жыл бұрын
I have a sneaky suspicion that Primeagen is Grug, Grug is Primeagen... heh!
@RolandKontson
@RolandKontson Жыл бұрын
Grug seems experienced :)
@ossman11
@ossman11 Жыл бұрын
I have been in a large team with thousands of E2E UI tests. For which one team their tests where flaky. After investigating found out that the testing API they wrote was flaky and once I fixed it concluded that their production code was just as flaky. Making me learn that flaky tests are good data about who don't know what they are doing. Somehow these people had the arrogance to claim to be the only one to know how to fix the flaky testing issue. Just switch to a different testing framework and only writing a tenth of the total amount of tests.
@br3nto
@br3nto Жыл бұрын
9:27 he’ll yeah!! No mocks!!
@d7ffab979
@d7ffab979 Жыл бұрын
bro you don't read in files all at once and then pass around all of the bytes, you read the stuff in small chunks (like 8 KB chunks or so) and then process it bit by bit.
@amin29a39
@amin29a39 Жыл бұрын
any source recommendation for testing ?
Жыл бұрын
If your complex function needs a 1 TB file, then have it take a stream instead of a 1 TB string, or make it work with partial data and loop it. It's really not hard.
@jacobdoran9433
@jacobdoran9433 Жыл бұрын
He remembered!
@shioli3927
@shioli3927 Жыл бұрын
Doing the whole "never integrate with your environment thing" is really really hard though. Very often you need little pieces of data that you do not know at the start of the function so you cannot really extract it out entirely. Then you can either mock part of your data access layer or run a local db or similar for the test. I sometimes prefer the latter, but the downside is that your tests that could have taken milliseconds now take seconds to complete.
@AlexanderNecheff
@AlexanderNecheff Жыл бұрын
How do you not know what the data should look like? Are you just jumping right in to implementing without having a definition of done pinned down?
@shioli3927
@shioli3927 Жыл бұрын
@AlexanderNecheff It´s not about not knowing the structure of the objects. More that you often have a loop that does xyz for a bunch of items doing one or more queries for each of them. When you have it as an input you have to select all the data at once or you cannot extract the db calls. If you do a lot of data shoveling on bigger datasets that gets unmanageable. You can´t just load 10gb of data into memory. You can say screw that i´m just gonna test it for a single item and assume the rest of the code is correct. It´s either that, mocking or running a db and injecting data for tests. You need a construct like streams to be able to put the data as an argument without actually putting the data as an argument (you did not read the file yet) for that to be viable for bigger sets of data. This very quickly becomes not straight forward if you are not working with file input or stdin but a one or more database and database like stores.
@asherrfacee
@asherrfacee 9 ай бұрын
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.
@covle9180
@covle9180 Жыл бұрын
Mocking bad. Fire pretty.
@ThePrimeTimeagen
@ThePrimeTimeagen Жыл бұрын
Agreed
@DarthVader11912
@DarthVader11912 7 ай бұрын
Welcome to Costco. I love you!!!!!!
@hananurrehman
@hananurrehman 10 ай бұрын
10:48 Michael Scott
@atanas-nikolov
@atanas-nikolov Жыл бұрын
Not a TDDer here, but in my understanding, unit tests ARE supposed to be deleted if your API or functionality changes. At that point you are not offering that service, so why test it? People should rather learn that most things don't need unit tests. You only test a total of 3 things: 1. Any incoming query - assert it returns what it should. 2. Any incoming command - assert it changes what it should, given it's somehow publicly accessible. 3. Any outgoing command - mock to see if it gets sent with the correct arguments. That's all. You don't go unit testing implementation, cuz grug club you in face.
@michaelpacheco7421
@michaelpacheco7421 Жыл бұрын
What is your github?
@S-we2gp
@S-we2gp 9 ай бұрын
I literally cant even accept anyones negative opinion on tests because i know they're not doing them right in the first place. The testing experts actually acknowledge that you cant test everything in every possible direction, but most people test nothing and when they do write tests they write them after they write the code which is effectively impossible to get right.
@d3stinYwOw
@d3stinYwOw Жыл бұрын
Talking about unit test? It's not Dave Farley, since he hates unit tests basically. :)
@VladKochetov
@VladKochetov Жыл бұрын
After “I hate UML” I thought that there would be a video “tests are not needed”
@SoggyBagelz
@SoggyBagelz Жыл бұрын
grug is a genius
@jful
@jful 8 ай бұрын
I see your testing pyramid and raise you one testing cone.
@VictorMartinez-vi7jx
@VictorMartinez-vi7jx Жыл бұрын
CONGRATULATIONS
@MaxHaydenChiz
@MaxHaydenChiz Жыл бұрын
Property testing is not used nearly enough. I think a lot of less experienced devs might not even know that quickcheck libraries are a thing that exists.
@kampanartsaardarewut422
@kampanartsaardarewut422 Жыл бұрын
Unit testing ought to use for testing the behavior not implementation.
@OlutunmidaTech
@OlutunmidaTech 2 ай бұрын
very funny, but i can totally relate 🤣🤣
@boot-strapper
@boot-strapper Жыл бұрын
flakey e2e tests arent the worst. At least if they fail enough times in a row you actually know something is wrong.
@kennethbass1915
@kennethbass1915 Жыл бұрын
I love mocking.
@zedekai9456
@zedekai9456 Жыл бұрын
Ooh repost?
@spicynoodle7419
@spicynoodle7419 Жыл бұрын
Yea get used to it, he has 3 channels and he posts the same thing like twice on each channel
@ThePrimeTimeagen
@ThePrimeTimeagen Жыл бұрын
I literally do not. This is not a repost.
@sutirk
@sutirk Жыл бұрын
Never seen a primeagen repost
@zedekai9456
@zedekai9456 Жыл бұрын
Yeah my bad!! I was delirious at 1am, 10 seconds in, and was thrown by seeing Grug again. Thought the Grug video might have been deleted and rereleased. Grug 1 was one of your funniest btw! Didn't mean to be rude 😊. Sorry if I was offensive.
@MojoMagicau
@MojoMagicau Жыл бұрын
Is truth. Is good.
@boomertester
@boomertester 2 ай бұрын
I know this is a year old, but I will fight you about mocking and stubbing. Bring me on your stream senpai. 👋👋👋
@RootsterAnon
@RootsterAnon Жыл бұрын
Congratz!!!!
@cubbucca
@cubbucca Жыл бұрын
I miss alerts
@paulogodinho3275
@paulogodinho3275 Жыл бұрын
I miss the notifications
@daniilsurnin795
@daniilsurnin795 Жыл бұрын
Mocks are shit, totally agree, are not representative at all
@imulion668
@imulion668 Жыл бұрын
Disliked since I didn't get to hear "Welcome to Cosco, I love you"
@davidadamson1588
@davidadamson1588 Жыл бұрын
dependency injection.
@yassinejk7860
@yassinejk7860 Жыл бұрын
Grub like
@vectorhacker-r2
@vectorhacker-r2 8 ай бұрын
TDD works
@liquidsnake6879
@liquidsnake6879 Жыл бұрын
answering the title: never, never and never. What's the next question?
@testolog
@testolog Жыл бұрын
Ok, first. Like me, after I edit to some shit:)
@uchennaofoma4624
@uchennaofoma4624 Жыл бұрын
Just got here
@amrshlomr
@amrshlomr 3 ай бұрын
dude i love u so much hahaha
@MrCalyho
@MrCalyho 7 ай бұрын
This reeks of people that doesn't know what the definition of tests are. There are books like CD, Devops Handbook and TDD, Also the Art of Unit testting etc.. The problem in the industry is that junior developers just pull things out of their ass and then try to sell it has law. Before making videos like this update yourselfs first and actually read what the thought leaders have been saying for tyhe past 30 years.
@programmer1356
@programmer1356 Жыл бұрын
Mocks are proof that OO is bollocks
@peterhuan-sr5pd
@peterhuan-sr5pd 6 ай бұрын
test
Maintainability And Readability | Prime Reacts
20:22
ThePrimeTime
Рет қаралды 109 М.
Dependency Injection | Prime Reacts
28:34
ThePrimeTime
Рет қаралды 360 М.
Une nouvelle voiture pour Noël 🥹
00:28
Nicocapone
Рет қаралды 9 МЛН
She made herself an ear of corn from his marmalade candies🌽🌽🌽
00:38
Valja & Maxim Family
Рет қаралды 18 МЛН
Don’t Do E2E Testing!
17:59
Continuous Delivery
Рет қаралды 160 М.
Lets Chat About Unit Tests
15:06
ThePrimeTime
Рет қаралды 101 М.
J B  Rainsberger   Integrated Tests Are A Scam HD
1:04:36
Christopher Cabanne
Рет қаралды 44 М.
You're Not Qualified To Have An Opinion On TDD | Prime Reacts
13:37
I Accidentally Saved HALF A MILLION $ | Prime Reacts
29:12
ThePrimeTime
Рет қаралды 383 М.
Agile Is Mid
11:06
ThePrimeTime
Рет қаралды 71 М.
GitHub Actions Feels Bad
26:27
fasterthanlime
Рет қаралды 98 М.
Why I Quit Netflix
7:11
ThePrimeagen
Рет қаралды 526 М.