Stop Writing So Many Tests

Testing is hard and knowing what to test is even harder. In this video I talk about the 3 different types of tests and how they compare to one another. I also talk about why end to end tests are so great and why writing less tests can make your test coverage better.
📚 Materials/References:
Pure Functions Video: • Learn Pure Functions I...
Pure Functions Article: blog.webdevsimplified.com/202...
Jest Video: • Introduction To Testin...
🌎 Find Me Here:
My Blog: blog.webdevsimplified.com
My Courses: courses.webdevsimplified.com
Patreon: / webdevsimplified
Twitter: / devsimplified
Discord: / discord
GitHub: github.com/WebDevSimplified
CodePen: codepen.io/WebDevSimplified
⏱️ Timestamps:
00:00 - Introduction
00:40 - Types of tests
02:55 - Comparison between test types
03:52 - When to use unit tests
06:35 - When to use end to end tests
08:18 - When to use integration tests
#Testing #WDS #E2ETests

[@gbroton]

From my experience, it is really hard to find good articles about unit testing. 99% of them are examples presenting silly "add" functions, which is completely useless for anyone who wrote at least one unit test. But in fact writing good unit tests is an art, and require some practice, but without any proper guidance it is hard to get there.

[@locim9201]

Agree…

[@pseudounknow5559]

Czy masz jakas strone internetowa albo filmik ktory dobrze to tlumaczy ?

[@bradleytaniguchi1187]

There is also the element of writing your actual code in such a way unit testing is effective, without writing too much extra code just for the sake of the test. It's very much a balancing act

[@attevirtanen271]

The clean code book

[@progressnwimuelekara2167]

I thought it was just me. Not many people make videos on actual software testing like they do on React, NodeJS etc. (writing actual code).

[@skycastlechronicles]

Thanks! I always wondered how testing actually works! That overview alone in the beginning of the video is gold!!

[@WiLDeveD]

I Love you Kyle for your kindness and Emotions about Audiences ❤❤❤ and pure content.

[@Pluvo2for1]

I've heard a lot of arguments around test type ratios at work, but I agree with you. The only thing I would say is that end to end tests are more difficult to work into daily work flow. Because they can take so long to run they are often not run on every commit, nor even each push. It's then harder to work out which commit caused the issue. And, earlier in a project, the UI may not be settled. This means that you'll spend a lot of time maintaining E2E tests. That time may not be factored into ticket points.

[@-taz-]

Yes, end to end tests are low value because they're slow to run, and when they fail, it's hardly ever clear why. If that's how we find logic errors, good luck. Plus, they're not trustworthy. They might include networks and databases which might fail during fairly normal operations, and then you're going to have to drop everything to go on a wild goose chase. The most seasoned veteran will warn people to avoid end to end tests entirely. (Personally I've been writing software for 31 years in dozens of languages, with the majority being C++ and Javascript now.) I have never used mocks or logs in my life. I write code to either succeed quietly, or fail with a clear reason why. And I write my tests the same way. We need to test all the logic without integrating I/O. If something does fail in production, it's because of some misconfiguration or disconnection, and that exact information is what should flow to whoever needs to fix it. A log message that has to be debugged by some developer is a total waste -- and yet it's what most of peers seem to be doing with their lives.

[@chrisbenjamin3072]

Another fantastic video, thanks Kyle!

[@abdessittirharkati7603]

Such a great point, thank you Kyle

[@rodrigolaporte274]

I couldn't agree more. And, as usual, you explained it perfectly!

[@marcusengel3700]

As you said - 100% agree!

[@raymondbyczko]

Good work! I am just about in total agreement with your conclusions. I would add that while unit tests can be reserved for critical pieces, they can also be used for just plain complicated ones. Also while function A works well on its own, and B works well too on its own, the execution of A and B (maybe A calls B) explores boundary conditions etc. There can be side effects that occur, that were unanticipated. A good end to end helps find these things. Again great work!

[@thekwoka4707]

Ideally static code analysis like with TypeScript would solve the boundary issue.

[@tdombui]

love how you have a single guitar and a pillow that says 'family' in the background

[@calkelpdiver]

I've been in Software Testing for 35 years now. And it comes down to being smart about what you test, and what you automate. There are different levels of testing and different way to automate the execution of those tests. It comes down to "risk" when determining what to test. Obviously the first thing to test is basic functionality (Smoke/Build Validation) of the system. Got to "plug it in" to make sure it doesn't go "POOF!" with a big cloud of smoke. Next is to test the key functionality using the 80/20 rule. Test the 20% of functionality used 80% of the time. These can be Integration, Functional, Business Scenario (End-to-End) type tests. Next is Negative Testing / Fault Injection to make sure the system under test will handle error conditions properly and not give you the "Blue Screen of Death". After that it is a question of what else can be squeezed into the schedule as additional testing tasks. Implementing Automation in Testing for the above should follow the same rules. Automate what makes sense and don't even attempt to get to 100% automation, it is a myth and a target you will never reach.

[@yt-sh]

Thanks for the tips!

[@jonjackson9174]

I figured I'd come to your latest video to ask, but I can't find any tutorials from you on redux. Would love to see one! Especially in conjunction with react and even typescript, but anything will do. No worries if not! But I love your breakdowns and would be very interested to hear your explanation on that tool. Much love!

[@businessoftechnology]

Usability Tests, and tools like Storybook do UI style testing to see changes don't creep in unexpected. Plus, if we do TDD then we don't take time to write tests post assumption of working code. Great TDD says we understand what we are coding before we start coding. :) Not perfect here either, but it is a continual growth target.

[@trandzung9311]

Nice video Kyle, love the content as always! I'm pretty new to testing. I have a question: Let's say I have a sales website, which type of test should I write first of the 3? As I understand it I should start e2e first, it allows me to know the scenario/testing requirement (interactions are requirement to the user) for the unit test, integration test. Because they are based on e2e test. Thank in advance.

[@andygr1n1]

Thanks, very good explanation

[@danielgruner]

Thanks for the video! I think e2e is king, especially with tools like Cypress or the relatively new Playwright. I will also use it for a daily check of my app. I have centralized logging and alerts set up, but these are only triggered when it's too late because they are caused by actions from real users. By running these e2e tests in a different infrastructure, you can test almost anything*: your app's infrastructure (servers, database, gateways, etc.), your app's functionality, external APIs and services, etc. - This is really powerful. *There are test scenarios for which e2e tests are not suitable, e.g. load tests or performance tests.

[@arvidj8918]

As someone who has been working with programming and unit testing for 10+ years and lecturing for 5, this is the best explanation about anything on the internet.

[@sabuein]

Again, thank you, Kyle.

[@_eric]

Needless to say this is a bit of a controversial video. While I am sure there are situations where your assessment is correct. There are equally counted situations where it may not be correct. While there is a place for all the types of tests you are talking about, Unit tests are still by a long shot, the most valuable tests. As many other viewers have commented, they run in a fraction of the time any other tests would run. When written properly, one can run 1000s of unit tests in a matter of seconds. Giving us instant feedback, faster builds, etc. Furthermore some of your complaints about the value of unit tests are usually the results of a lack of design in the first place. What I mean by that is that when a unit is built, its interactions must be defined. When a new component is built in the UI, we need to define all its inputs and outputs, as well as describing all its interactions with other components or subsystems (like http calls). Part of that contract includes corner cases and exceptional situations. And those are the ones that get extremely hard and expensive to test at a higher level of test (integration or e2e). In your example of the ToDo tests, I would argue that the e2e value of doing basic tests for the 4 major operations (CRUD) is very low. Those tests cases are so core to your application that they can be tested by a human in no time. However, testing situations where the network is slow, there is a duplicate task, the user clicks twice, the database is busy for like 2s while a user is updating their list, etc. those are situations that are just as critical, if not more critical and are extremely hard to test in e2e or integration layers. However, they are trivial to test at the unit-test layer. I have always enjoyed your videos and always welcome your ideas. I would just caution against making blanket statements to your growing audience that _unit tests are useless and you should only write e2e tests_ (I know it's not exactly what you said, but that's what some inexperienced viewers will retain from the video...)

[@kadrolarino6141]

Thanx a lot for your effort could you please make a course or video about clean architecture?

[@OSA413]

If it takes a lot of effort to make a test stub to work exactly as the target component it's easier to make the actual component to take part in the test. Since then I started writing only e2e/integration tests.

[@stojadinovicp]

And if your end2end fails? Good luck debugging... I'll do my unit tests and go up - looking for "bad" combos of those units. Bottom up makes way more sense than top down. And is cleaner, safer and in the end saves time.

[@DanielMaldonadoPC]

Does console.log every time you make a change count as testing

[@ridl27]

I see you're a man of culture bro

[@sydneymccarty5501]

Yes and No. Read about Regression Testing

[@hunahpuyamamoto3964]

I like this philosophy. It takes a lot of experience to realize these things. My view today is: If your code can kill somebody or cost your client a lot of money, test the hell out of it. Write all the tests needed to build a 99+% confidence in its reliability. Otherwise write tests for the critical parts: Functions, persistence, edge cases, etc. Test the other parts the old way-Checklists, user assistance/feedback. You will save so much time this way.

[@vladpopa33]

I like to think that unit tests are like a linter, making sure you're calling a function with the correct type, order and number of parameters; and e2e tests are used for testing the logic of your code.

[@sominupadhyaya9026]

Nice vid Kyle, love the content as always

[@isi1044]

How can u love the content when you haven't watched the whole thing

[@douglascounts4634]

@@isi1044 I was thinking the same thing. They post that they "love the content" when they haven't even watched it yet.

[@theodorealenas3171]

I improvised an end to end test for zipping my files before sending them to the professor. It would unzip and check them. What's not obvious is that, what that actually helped for, is sending more versions to the professor as I was working on the project, because there was less effort or hesitation. I love automated tests. I want to get good now, before I graduate. I didn't know by the way that what I did is called end to end test.

[@Born2EditHD]

I wrote something like 168 tests for my latest project and it worked perfectly. I always knew exactly what was wrong when the app stops working.

[@trappedcat3615]

until you introduce it to 1 million customers...

[@devPunks]

Then you write tests for the bugs they find and add those to the suite. The pushback on testing is like arguing why showering takes too much time. 🤢

[@Born2EditHD]

@@devPunks that depends on what the bug is. If a new feature is required to fix the bug then you test that new feature. If an existing test has failed due to a bug or if a test doesn't check for a condition correctly then you fix that test/the code that it's testing

[@devPunks]

@@Born2EditHD FALSE. A "New Feature" is NOT a "bug fix". SHEESH. A new feature is a new feature and a bug fix is a bug fix. You don't make a new feature to fix a bug. There is no one stop one type of "that is testing". I'm gonna need a link to your github account and see some of these tests you write. You sound like you've read a couple tutorials on testing not actually built software that people use. Just send your github URL with examples to your "That's how you test" examples.

[@Born2EditHD]

@@devPunks sounds like you've never actually worked on large scale software 😂 some bugs require entirely new features to fix. Remember, a bug is defined as any behaviour that does not act in the way that it is expected to.

[@ericplante3237]

To me, unit testing helps reviewing what I ve coded to find missing requirements and make improvements and refactoring. It is a change of point of view to find flaws by being as exhaustive as possible with the test cases. It takes a lot of time, yes, but it is proven to worth it in a long run. When I m done with Unit Tests, the only benifit of E2E is to test the behavior with external systems and the UI interactions. The other benefit is to validate the integrity of any changes made that affects the tested code.

[@geebsayshi]

I think it really just depends on what phase of the development I’m in. Endpoint (functions alone) = unit test Endpoint + DB = integration test Endpoint + DB + Frontend = unit tests I favor integration test for TDD. If I already wrote integration tests during API development, I just don’t bother about E2E test except I really got time.

[@isi1044]

I don't write tests 💪

[@douglascounts4634]

That is its own test. It is a does-my-app-suddenly-crash-and-burn for some unfathomable reason test? Or if you did something for a client, then it is the will-this-customer-ever-hire-me-again-test after I crashed their app?

[@DannyMancheno]

Writing perfect code is the truest of tests!

[@antonkonovalov8902]

You doing tests wrong

[@arihantjain8347]

They want coverage above 70%🥲, I can't mock redux 🥲

[@rafaelbenetton3674]

You cannot fail tests if you don't write tests, that's a good approach

[@hicoop]

I'm pretty new to testing. Is there a major difference between cypress and playwright?

[@michaelangelojong]

Just as there are different kind of test, we can write code in different ways. As mentioned in the video pure functions are super easy to unit test. If you need to mock things there are things you can do; either stop mocking things and just do large integration tests or try to separate the pure business logic from the I/O that you are mocking. By separating the pure business logic from I/O you can make unit tests that just test the business logic and then make some integration test that just test the integration (I/O)

[@JordashTalon]

Do you have any videos on Integration Tests / End to End Testing processes?

[@ravisankar5099]

Please make a video on microfrontends

[@Nil-js4bf]

Writing trivial tests is soul draining. I absolutely abhor the unit tests that mock everything. Especially when it's testing a function that integrates a whole bunch of other functions. The test ends up looking like - assert function 1 was called 1 time with these params, assert function 2 was called 1 time with these params, assert function 3 wasn't called. It's so incredibly stupid and the test is essentially rewriting the implementation.

[@-taz-]

I hate those too, and the only thing I'd do with that is delete it. That's not unit testing. That's testing implementation details, which is not part of ANY test methodology. That's like saying "assert the function I wrote is the function I wrote."

[@Treborbobuk]

If you are having to mock/fake a lot of stuff to make a unit test work, then it's because the architecture is poor - too many dependencies etc... Unit tests are wonderful when it comes to refactoring code, that's the main purpose of them, not to replace manual QA / regression testing. Unit tests give devs confidence that changes to code have not changed the output of the code. E2E , visual testing etc... are replacing humans doing QA, not in any sense comparable to writing test code. Good video, but the different types of test are not either/or choices, they are all necessary and serve different purposes.

[@ytxzw]

xd

[@juanpasten6077]

Thanks!

[@PrzemysawSech]

Generally, I love the content in this channel. However, this one is so wrong, I struggle where to start commenting. The following is my personal opinion, based on over 10 years in QA automation. E2E tests are genetic, on failure they say 'something is broken', where unit tests highlight the specific line of code and the reason. E2E are prone to false positives, they suffer from network latency and 3rd party dependencies. The cost of maintenance is much higher that unit or integration tests. E2E involve backend thus an app must be deployed to an environment, which increases the cost. This also makes the feedback super slow, where unit, integration, contact tests are build-time test, which makes them cheaper and faster. As a Software QA I spent years in E2E area. In my opinion the test pyramid pattern is right to apply. There should be as few E2E as possible. I treat these as post-deployment smoke and infrastructure tests. If you want to assure quality of BE-FE integration, use contract tests.

[@locim9201]

May I confirm if you’re referring to contact centre tests? As this is the first time I know and that’s what I can google😂. Would love to know why it could assure the FE-BE quality so much

[@palyanytsia]

Maybe contRact, not contact?

[@locim9201]

@@palyanytsia seems making more sense, thanks man

[@jordondax]

It's strange how you definitively say someone is wrong, then highlight you're about to give an opinion. How can anyone take you seriously?

[@sismith5427]

@@jordondaxIf a persons job is literally only concerned with writing effective tests... and has been employed for 10 years writing test suites, I'd probably say their opinions are valid. As a developer I generally respect the opinions of experienced Automation test engineers on what makes effective test coverage...

[@Trazynn]

Can you do something with randomness?

[@just_O]

I like "Assurance" but personally I prefer "Confident". Use what you want the thing is don't rely to much on coverage, it doesn't mean what your boss think it means, and it's part of your job to make him/her see it

[@AgentZeroNine1]

When and where do component tests come in?

[@yamogebrewold8620]

I still think that unit tests play an important role. Some developers avoid covering their essential core business models with unit tests, with the claim that the only relevant tests are E2E and integration. They claim that unit tests don't prove much and have little worth. I think this claim is wrong, because a unit test can point to where something is broken. You get an early signal that a certain part of the software is no longer working as expected. And you also get the exact location in the codebase where something is no longer working. An E2E test will tell you that a user flow is broken. But you can't always rely on it to tell you why the user flow no longer works and where the issue may be. And if the system is complex and composed of many subsystems, the problem is bigger. Unit tests help us debug issues at an earlier stage.

[@jasonleelawlight]

Right, the problem for a lot of the devs regarding unit tests is that they don't have a clear view of what unit test is about and what it is not, and some of them even impractically expect unit tests to capture all kinds of bugs which lead to many stupid decisions.

[@dmitrykim3096]

Unit tests are useful if you have an algorithm and you need to debig it withiut running the whole infrastructure

[@baka_baca]

Code coverage is great at false assurances. I used to be on the bandwagon, but seeing the bugs still roll in with 100% coverage is far from great and honestly just a pain in the butt.

[@avoerman89]

I like how Kent Dodds puts it... "Write fewer, longer tests"

[@anonNemo]

it make sense if you are working on small scale projects with minimal financial impact. the thing is that, not all projects are created equal. this explanation might be true for most applications out there but when a project gets too large for one team. and too slow for a few hundreds of thousands of people. and too complicated to change. then you'll see the difference. Unit testing is not only for testing. it is for proper design. code that can be easily unit tested is code that is easy to changes. it saves on maintenance/change/enhancement/etc cost which is 70% of the software cost.

[@leopolon]

About the "code assurance". My understanding is that the end goal of testing is to increase confidence that the application works (code assurance) while code coverage Is just a metric.

[@-taz-]

My viewpoint has changed to say that the end goal of testing is to develop and document high quality software. The unit tests are "executable documentation" that supplies the intent of the software, including its behavior and business goals. Code coverage is just a metric, definitely, and I never considered it an important one. If one really needs a tool to tell them what they missed, that's a problem! But also, even 100% coverage does not imply that all necessary paths are covered.

[@arshadsiddiqui9071]

When that cypress video dropping?

[@emreq9124]

What if projects has CI and you have to pass 100% coverage then ?

[@Charliepinman]

It’s funny this is a topic I brought up at work their standard is 80%, a small company writing non critical tests doesn’t make as much sense as writing tests that test important user flows Im gonna send them this video

[@DeadRobin]

At 2:48 "Unit" moves alittle bit down, you 're welcome

[@smoofwah3552]

Hi mom famous, here before 50000 like comment gets big.

[@tdsora]

what's the difference between end to end test and integration test? In my mind they're basically the same. You're still using cypress in both of them.

[@genechristiansomoza4931]

End to end test manipulates the front end to test while integration test you directly using the methods in the backend to test.

[@tdsora]

@@genechristiansomoza4931 that's not a widely accepted distinction of end to end test vs integration tests

[@_danyg_]

The biggest problem in unit test that everyone does, is unit is not a piece of the architecture you created to solve the problem, the unit should be a slice of the problem. Unit is functionality, test functionality, don't test your approach to the solution, you are only asserting that you did what you did. Mockist vs Classists, Testing Outside in, these are concept associated to TDD, but regardless of your opinions in when to write the test, is important to understand why there is a pyramid of test. Feedback, how long you need to wait until you are certain your code is production ready. @Web Dev Simplified, can you do your E2E test when there is no backend to call? not even a specification? if so how you do? do you abstract that in an adapter / an anti-corruption layer? to be defined later? so are your E2E really End to End or are integration tests until the backend is ready? or do you do waterfall and you do not start FE work until backend is ready? The test strategy is very tight to the architecture, loosely coupled architectures allow testing and work towards more agile approaches and the test strategy allow and incentivices more unit tests where those are actually testing functionality in a vertical stack, integrations test in a horizontal stack, and e2e just a version of integration test that actually don't use fake servers. But following the pyramid of testing. The idea is that when you are developing, you know as soon as possible when you broke the system, nimble unit tests testing functionality will give you that fast feedback. Waiting until E2E ran might be too late. Maybe you could get deeper in this concepts in your videos, as is easy for devs that are learning to take your word for it, and then end up in situations where development to production takes validations of 6 to 10hs of running e2e tests. (which I saw many times sadly)

[@dmitrykim3096]

You need to mention it depends on the project and requirements.

[@dmitrykim3096]

I mean there are some huge backend projects that has a lot of devs working on the same code, unit tests are for testing regressions to make sure that some other developers won't destroy your class because he didn't understand how it's supper to be used

[@erastvandoren]

I hardly ever write unit tests, only if I have some complex logic testable in isolation. I write mostly integration tests, and virtually never mock anything.

[@gosnooky]

I find writing useful tests takes 2x longer than actually writing the code.

[@user-xc5cx7lh4l]

Pure business logic should be unit tested with 300% coverage.

[@garymathe9863]

Exactly. I blame the outdated 'test pyramid' where unit tests are the most abundant at the bottom. Doesn't need to be that way. When it comes to testing strategy, everyone should think for themselves by taking into consideration what tools/skills and how much time they have, and how critical certain elements are to the application.

[@andyengle]

This is absolutely true. At some point, tests become a liability because, like other code, they must also be maintained.

[@EricSundquistKC]

I feel like half my job is finding out why the E2Es failed and if I can prevent that failure in the future

[@-taz-]

The way I see it, code must be maintained which is why code itself is the liability, and unit tests (which I call executable specifications) use the speed and perfect accuracy of a machine to help me do that efficiently. Plus they also document clearly how the software is intended to work and what value it is intended to deliver.

[@Greedygoblingames]

I was just watching a video of Dave Farley's titled "Don't do End to End testing!"... sometimes, I just feel lost... 😕

[@ExploringCodeCrafter]

Try it out and you will see why you dont't want to write E2E tests. To give you an example. Someone Changes a CSS class in any other component, which could cause your test to fail. Use E2E Test only for fewvof for your main usecase because they are high in cost an low in Performance.

[@peerreynders1824]

1. Who do you think has more experience when it comes to writing and testing software? 2. Look for Martin Fowler's article “On the Diverse And Fantastical Shapes of Testing” to understand the confusion that exists in FE regarding the role of tests. And in particular pay attention to the distinction between solitary versus sociable tests. 3. Watch the video of Ian Cooper's talk “TDD, Where Did It All Go Wrong” to understand how unit testing or developer testing is usually misunderstood. Developer tests exist to detect unintentional changes as quickly as possible. That isn't the same as verifying that the code is “correct”. Developer tests cannot verify correctness, they should only verify *quickly* that it behaves as designed. Developer tests cannot demonstrate that the designed behaviour will lead to correct application behaviour. Developer tests are supposed to fail *quickly* when refactoring or adding a new feature unintentionally breaks already existing, designed behaviour.

[@bigdamo21635]

You don't seem to use the plural of test? or the mic doesn't pick up on the 's'? (Tests)

[@FiveTwo_Nick]

Wow, the last time I was here, Kyle was still an unmarried man

[@natalieeuley1734]

Use end to end tests to cover as much as you can and unit tests for all those annoying little cases that would be difficult to test in a complete workflow. A great example of this is e2e to test the form functionality, but then unit tests for all the logic surrounding possible date field values

[@-taz-]

That's a good point. Failures can't be tested so easily with E2E. Those must be done with unit tests. Plus only a unit test can be 100% reliable, and practically instant. E2E tests cannot compete. E2E can just make sure stuff is connected. Is that something for human testers to do? No. That's what monitoring is for.

[@viet.khoaiegg]

I still write a lot of unit tests and mock a lot of fake responses from API just for passing the test 😂 because my company requires me to do that

[@devPunks]

The pushback on testing is like watching people argue why taking a shower is a waste of valuable time. WASH YOUR ASS! Aesop's Fox & the Grapes.

[@manicmastermind]

I agree with some of what you say but a lot I don't. E2E tests are slow, fragile and completely impractical for large complex systems. Martin Fowler has a great blog post about the testing pyramid. The tools are out of date but the concepts still apply. I'm a little surprised that as an industry we haven't moved to TDD as a standard.

[@-taz-]

TDD is good but BDD is better. :)

[@kovalpeter]

In the first part of the video, the author tells the unit tests do not provide good coverage, and 2 seconds after that tells that the unit tests provide nearly 100% coverage. A code assurance? Something just came up? I would prefer a more mature, proofread discussion. The code coverage is easy to define and count. The code assurance is not defined. Can we define it as a number of actions tested versus the number of implemented actions?

[@jeremykothe2847]

This doesn't scale. Apps past a certain size have too many possible states to test end-to-end. With higher-level tests and time being a thing, you can only simulate an increasingly vanishingly small fraction of the possible states your app might be in. That's why "we" invented unit testing. It's a pyramid... Your end-to-end tests are there to ensure the assumptions your integration tests make are valid. Your integration tests are there to ensure the assumptions your unit tests make are valid. Your unit tests are there to ensure that when an application state not covered by the integration or end-to-end tests is encountered, you can still be confident things will work. Unit tests are the foundation of the pyramid, integration tests are making sure each room or section of the pyramid hangs together, end-to-end is looking at the pyramid from the outside saying "well it stands up, I trust the insides are fine".

[@joseluispaternina]

07:08 all they are cool coding and testing, wow what a bunch of happinnes. But 5 seconds after they realize it doesn't compile, becomes reality 😅

[@veavictus3683]

How can I write less tests than 0?

[@oanarcocaipira3865]

My tests has more lines than my code hahaha😂

[@Marcos-zx6ey]

Laughs painfully

[@drivearchive]

hate say it but copilot is really good at reducing my time in writing integration test

[@louie0187]

"Testing can prove the presence of bugs, but not their absence" -- Dijkstra

[@mathboy8188]

First time I've seen a video of yours whose argument I disagree with. That's not to say that end-to-end tests aren't important; they are. But unit tests are most numerous for good reason, and it's not just that they're the easiest to create. If anything, un-automated E2E testing, aka "bang testing" (bang on it and see if you can break it), is the easiest - and slowest - of all testing, and so is the lazy developer's "best" testing method. I could write a small treatise here about the value of thorough unit testing, but I'll just point out: 1. End to end can never be as thorough as unit testing. If you have a gizmo whose behavior depends on 20 parts, each of which must perform one of 5 actions, then you can unit test 5 times 20 gizmo-part possibilities, or end-to-end test 5^20 gizmo-system possibilities. So to completely test it, that's 100 unit tests, versus 5^20 = 10^20/2^20 ~10^20/(10^3)^2 = 100 trillion E2E tests. 2. The scaffolding/mocking/faking issue raised isn't much of an issue, as tools exist to help do this. And this effort is minimized further if you've coded (and designed/architect-ed) with testing in mind (see: TDD/BDD). Moreover, once you've got a mock file system or database or web service or whatever, you have it for all of your unit tests. 3. With unit tests you catch bugs upstream ASAP, which makes fixing them as quick and easy as possible. E2E tests take a long time (when they can be automated at all), whereas unit tests don't. Thus catching errors early - at the developer machine, or upon check-in/commit, or at worst within a few minutes of a commit - is far far easier with unit tests. Upstream is always better. For instance, if you wait until the end of the day and have even automated E2E tests, then everything that happened that day is the possible cause of any detected bug. 4. With unit tests, tracking down a bug is far FAR easier than with E2E tests. For bugs that are consequences of system-interaction problems, having unit tests still helps greatly, because it tells you what you DON'T need to consider. 5. Unit tests are exactly and reliably repeatable (if done right). E2E tests rely on hardware behaviors and configurations and such of the testing platform (which better not be the production platform!). Stressing E2E tests creates a cousin of the most dreaded QA responses to a reported bug: "Could not reproduce" and "but it works on my machine". 6. Suppose you do good testing and release it... and it's got a problem. If you emphasized unit testing, you start by knowing everywhere you DON'T need to look. If you stressed E2E testing, you start with "Oh crap!". 7. Back in the day before Agile & Xtreme approaches existed, I had a boss whose most repeated catch phrase was "But that'll break everything!". Hmmm... will it? Unit tests provide the confidence to refactor bad code and know that you probably "didn't break everything". By contrast, QA via E2E testing instills the fear heard in another of my old boss's favorite sayings: "DON'T TOUCH THAT!". 8. Without going into another small essay, TDD/BDD really are the way to go. A consequence of following such approaches is that you're guaranteed to have massive unit test coverage (in theory, almost 100%) just by the doing a developer's work day's routine activities. There's a weird - in a good way - feeling to saying "I've got the test names right, so the rest is just details.". Yes, at least for me, just getting the test NAMES right gives me that feeling.

[@EricFressange]

Mabl is a good tool for end to end test

[@user-wp8cp8gj8s]

So why do it wrong both ways if you can spend less time not writing tests)

[@beepst]

And to think I'm here always feeling guilty because I never write any tests

[@federicodibernardo2719]

Never write a Test in 10+ years and many company change (and the reason of change is not relative to missing tests, lol)

[@martinstu8400]

you probably are in debt from all that makeup you have to buy

[@nothingisreal6345]

this whole testing situation is a caused by cultures. today a lot of code is written by people from asian cultures. In these cultures avoiding uncesurity and reputation loss is very important. also effectiness and efficiency don't matter that much. it is: work hard! if you fail and didn't work hard that is very bad. if you worked hard but still fail - that's carma. unfortunately that collides with the reality of computers. computers as such are incredibly realiable. something that has been tested once to work typically does not need to be tested again elsewhere. so to write a test for function sum(a,b) { return a+b;} with a test like Assert.AreEquals(sum(2,2), 4) effectivly tests if the compier / interpreter works - which is usually FUTILE - it does. but writting these tests makes it look as if you did work hard and gives you the false gut feeling of security. write tests for things your are not sure about, and then have someone else test what you wrote. that typicallcy gives the best results. test for boundary conditions and important: test for non specified requirements. Mocking a DB is nonsense. Typically issues with DB arise when scaling to huge amounts of data (O(N²) and unusual data (95% have flag X set to 1 and 5% have it set to 0 and you have an index on flag X). and before investing tons of time in writting test: first understand the requirements, then understand the technology, then add common knowledge (as all requirements are incomplete).

[@RedShift5]

Production IS the test

[@snake1625b]

Imo Gui testing is too much to maintain and most of the failures are false positives. The extra time to write and maintain them is not worth than just testing it manually

[@khaled-0]

Tests, What do you mean?

[@joancomasfdz]

I've been saying that for years now, but it goes against a big part of my organization. I've developed easy, intuitive tools to write end to end tests. I've told my teams to start any story by writing the end to end tests, for happy paths or modifying the existing ones. But pleas stop adding milions of nonsensical unit tests that bring 0 value in confidence and documentation and are just a burden to rapidly change the software as needed.

[@jamessullenriot]

I find that a lot of tests (especially unit tests) are written as "busy" work. Most of the big things of you app will be tested naturally. But beyond the obvious things that could break, lots of people just start testing random things that don't matter so much so that your test suite becomes more to manage than the actual code you are writing these tests for.

[@nsubugakasozi7101]

I think the advice here is kind of wrong. Using your example of testing the add and divide functions separately...there must be some place, some method that actually calls both of those functions together. That method would also be unit tested to make sure its calling stuff in the right order. E2E tests and integration tests take forever to run, are unclear in regards to where the problem is when they fail and are generally hard to scale ie the more code, the more tests, the longer they run....its not uncommon to find these things taking 1 hour or more to run.

[@dasten123]

My users test for me by using the application.

[@dukeboygamingchannel5906]

hi kyle

[@trappedcat3615]

Use of try...catch and feature detection in the right areas eliminates about 90% of tests.

[@rishiraj2548]

👍👍

[@AndrewTSq]

Have never written tests, but have tested with real people instead.

[@trailblazer3889]

Unit test: Mock all dependencies. Integration test: Test what you deploy and mock everything else. In the front end, you mock the API response E2E test: test everything. Automated QA

[@huseynfy]

👍👍👍

[@T1Oracle]

Integration tests are fragile, slow, require maintenance, have intermittent failures E2E is just another integration test with horrible scalability. The proper use of integration testing is when you need to verify something that cannot be readily unit tested. Also, the reason why you have to mock so much, is because you are using libraries that have poor testability.

[@rtl6832]

Tests*

[@mountakhabi]

Cypress ? 😂 Just try Playwright bro it will blow your mind

[@durara4492]

This! I’m working on a project at work transferring test cases from cypress to playwright. Playwright is by far the best the easiest to learn and use. 😊

[@Daddyjs]

unit test for our unit test?? 🤣

[@jamalkheirbeik]

You can't write too many tests if you don't write them at all

[@yangsong8812]

don’t skim on unit test. They are useful