5 Types of Testing Software Every Developer Needs to Know!

[@RahulGupta-lq3px]

Better than any video I've seen on the Internet on this topic. Useful for both client and testers. Great Work!

[@yassinesedjari1880]

Thanks Alex, concise and straight to the point explanation. 👌

[@alexhyettdev]

You're welcome, I hope it was useful for you.

[@kcayushma]

Got the concept in 6 mins vs 3hr of lectures and mediocre bragging thank you 🙏

[@NaftuliSinger]

Great straight to the point video! Thank you!

[@codewithbru]

This video was very useful, thank you very much! Your editing is amazing :)

[@alexhyettdev]

Thank you! I am glad it was useful.

[@Jelvix]

Hi! Thanks for this video! It's incredibly helpful, especially for those who are just beginning their journey. It's great that you are sharing your knowledges. Our QA team also created good video for QA and future QA - we collected the software testing trends for 2024

[@TheAnonJohn]

hello, informative video. As per ISTQB the testing pyramid consist of 4 levels : unit tests at the bottom, then integration, then system and finally acceptance testing at the very top. Is this the same pyramid as yours in the video or a somewhat different version?

[@AnkitTiwari-dq7qm]

Good explanation❤️

[@alexhyettdev]

Thank you, I am glad you liked it.

[@Gimmy27]

wouldn't you need n+1 tests instead of 2^n for mcdc?

[@チョリパン-j4f]

thanks great explanation!!

[@markodjordjevic6920]

Great video, I have just one question. What are API tests ? They seem to me like they are actually component tests, but these naming conventions can be quite confusing.

[@zentelia3666]

API testing, a subset of component testing, focuses on evaluating the functionality, reliability, performance, and security of application programming interfaces (APIs) to ensure seamless communication between different software components and systems. Basically in Component or Integration testing, you use the program API to do your test.

[@grokitall]

i would tend to disagree. an api is in general a stable set of interfaces between one set of code and another. when you publish code for others to use, you declare that the published interfaces will remain stable through bug fixes and extensions, only breaking with major new versions where the code could not be fixed without breaking the api. when you write your tests against the public api, you test that you have not broken things for the users of that code, while allowing the code the ability to mutate underneath the api in any way needed to improve the code. any code not covered by api tests is either exercised by the code behind the api, and thus tested by the api tests, or is dead code, and can just be deleted. the customer in this case can either be your own higher level code, or somebody else using your api, and the code behind the api generally gets split out into a new library which other programs then don't have to reimplement themselves.

[@RonnieDenzel]

Best summary for all the types of tests and their importance than any other video on the web💯

[@melk48111]

what about regression test?

[@fxstreamer238]

easier said than done thats why litterally no youtuber evr wrote a unit test in their life

[@terry-]

Great!

[@yantaosong]

thanks ,Alex , but can't understand the component test .

[@Lu149]

think if you're testing a car. You would want to test the engine on its own (component testing). The individual parts of the engine will also need to be tested i.e fuel injectors (unit testing). Then you want to test how the engine fits into the car model (integration testing)

[@Yon-ld9pk]

🤘

[@DaveThomson]

Every Lions fan knows MC DC stands for Motor City Dan Campbell

[@kazian5453]

Why are we still teaching a model that is 15 years old? None of our software architectures follow the same patterns as what was popular in 2009. Many of the struggles that we saw in 2009 that puts UI and E2E tests at the top of the pyramid no longer exist.

[@alephNull_]

They still do, it depends on your industry. In embedded SE things move slower, tests are more difficult, and a significant amount of testing could be physical 😅

[@grokitall]

not only does it depend on the industry, but also on the type of code being written. end to end tests and even more so ui tests tend to be fragile, with multiple levels of detail hiding, and often the best answer you can get from them is that it broke. it is often very hard to determine with these types of tests why it broke, hence the comment in the video about needing stack traces. even worse, when the code was designed without testing in mind, you often end up having to break information hiding to get them to run at all, at which point you are no longer testing just the api, but are adding implementation details to get it to run at all. the test then breaks when you change these details, even though you did not change the api. this is why you can tell how the code was developed, as doing test first moves everything without side effects down the pyramid, leaving your stuff with side effect being much smaller, and thus easier to test. it also fundamentally changes the nature of this code to make it testable through the stable api. this leaves you with a thin ui on top of a more modular, better separated code base, making changing from a command line to a gui to a web ui fairly simple. when you do minimal testing before coding, your code tends to be more coupled, harder to test, with a lot of the stuff which does not need to be embedded inside the ui code. combine this with ui and end to end testing, and the tests are a pain to write, even more of a pain to maintain, and don't give a very clear picture of what broke and how it broke. as you can imagine this leads o lot of ui and end to end proponents writing very few tests, and those tests provide minimal value and break a lot, reinforcing their dislike of testing and making all testing seem pointless due to their problems with using high level, low value tests on legacy code bases which were not designed to be testable. when you do test first, you fundamentally change that dynamic, as the tests are very fast, run against the public api, and tell you exactly what broke and why. for example saying that function x returned value y and should have returned z instead, when passed the parameters a,b and c. as they also run against every change, you know it was the bit you just changed that broke it, what the correct answer should be, and what wrong answer you got instead. this fast and detailed feedback with every change minimises the debugging cost a lot, to the extent that some projects with millions of lines of code spend very little time actually debugging code. of course the cost is that you have to write the tests first, and run them with every change, but the benefit is massive savings on debugging time if you write the tests well, and code which is easier to test, and to maintain.

[@laynierpiedra8278]

can you speak slow? Thanks for the info

[@krausi2]

speak slower......

[@Lisa__g06]

Seriously, more steps for quick and efficient refunds?

[@ashleyzimmermann5503]

Thank you!! So helpful!

[@khushsanghavi8805]

excellent explanation...just one doubt...what is the exact difference between component and integration testing then?

[@alexhyettdev]

So component testing is testing a component in isolation from everything else. So think of an API but with any external API calls and the database mocked out. Integration testing is testing multiple components together.

[@grokitall]

the only comment i would make to that is that if you do test first development, you don't tend to write your code so that they need mocking in the first place, and all of the code which has side effects moves to the edge of the system, where the rest doesn't need component tests, and the bit which does have side effects tends to become ui or end to end tests, meaning that for people doing test first, component testing tends to completely disappear from the pyramid. i would therfore tend to view the existence of component test as a sign of poor design and lack of upfront testing.

[@НашажизньвоФлориде]

Alex thank you for your video, it was very useful. Could you please give an example of a component testing for example on Facebook login page’s.

[@chenfry8849]

Your MCDC explanation is incorrect, you would need 4 for this senario. you need to show how each variable affects the outcome. The coverage you explained is predicate coverage, which is higher subsumption than MCDC.

[@gaerinraj2336]

Thank you very much. Very clearly explained

[@angellopez6687]

Very informative!

[@rishichoubey5060]

too fast ! and not good accent

[@ukaszkiepas57]

thanks a lot

[@alexhyettdev]

You’re welcome!

[@danieloyagha100]

Awesome

[@coachobispersonalworkoutti2223]

jUST ONE QUESTION ARE THESE THE LEVELS OF TESTING OR TYPES OF TESTING

[@justaQAstudent]

i think levels

[@grokitall]

if you exclude component testing, you end up with multiple levels which group together to do different things. when doing modern agile development practices, every test written by the developer when the code is being written is either a unit test, or an integration test, both done against the public api in the code. these two together form the regression tests used by continuous integration to test if the code continues doing what the developer intended it to do. on top of that you get your acceptance tests which includes end to end and user interface tests, but also includes the security testing, performance testing, and all other tests not directly related to if it does as the developer intended. these are used by continuous delivery systems to try and find out if any aspect except functionality broke, ie performance, memory usage, etc, and are designed to determine if what the developer intended matched what the customer wants and needs, leaving you with a system you can now deploy. component testing as described in the video and other comments seems to mix some of these things up in ways not in general usage. the functional tests used in continuous integration are designed to have the entire suite of tests run in under 5 minutes on the developers machine, to provide rapid feedback on if your new code broke functionality, and nothing else. you then push upstream, triggering upstream to do both types of testing to show if the code is deployable. this is designed to have a good enough testing environment that either the entire suite can run in an hour, or at worst that the suite can be run overnight to prevent problems with the non functional requirements making the code run worse. component testing as described seems to mix all of these different types of tests together, based not upon their purpose, but upon how they are implemented, and then adds another layer of complication due to having to do lots of mocking to get around the fact that the code under test was not written to be tested. these tests cease to exist as a separate category when you do test first development, as you don't write the sort of code that needs lots of mocks, and the rest is split by purpose.

[@kodnzikus]

Good stuff!

[@alexhyettdev]

Thanks! I am glad you enjoyed.

[@markveszelka376]

Interestingly, you mention unit testing and component testing as different levels of the pyramid, but regarding the ISTQB Foundation Level Syllabus: v 4.0: 'Component testing (also known as unit testing) focuses on testing components in isolation' v 3.1.1: 'Component testing (also known as unit or module testing) focuses on components that are separately testable.' Great video anyway! :)