5 Types of Testing Software Every Developer Needs to Know!

Рет қаралды 59,027

Күн бұрын

Software testing is a critical part of programming, and it is important that you understand these 5 types of testing that are used in software development. In this video, I go over the importance of the software testing pyramid and explain how the testing changes at each level. I also touch on MC/DC code coverage, which is critical if you every want to work in defence or aviation.
☕️ I don’t accept paid sponsorships and I have turned off mid-video ads. You’re welcome! If you would like to support my channel see: ko-fi.com/alexhyett
📨 Join my free weekly newsletter for advice, technology and more: newsletter.alexhyett.com
If you want to learn a bit more about how to test your software, then Zero To Mastery have a great course on testing that is worth checking out: academy.zerotomastery.io/a/af...
🗺️ Backend Developer Roadmap: www.alexhyett.com/backend-dev...
📝 Related blog post: alexhyett.com/types-of-testing/
🎓 RECOMMENDED COURSES (Use code FRIENDS10 for 10% off)
The Complete Web Developer Course - academy.zerotomastery.io/a/af...
The Complete Junior to Senior Web Developer Roadmap - academy.zerotomastery.io/a/af...
Complete SQL + Databases Bootcamp - academy.zerotomastery.io/a/af...
📚 RECOMMENDED BOOKS
Clean Code - geni.us/5AEwj2
Clean Architecture - geni.us/yBrTX
Domain Driven Design - geni.us/WiR0Q0x
Design Patterns - geni.us/5ncUt
Developer Hegemony - geni.us/lAXy
Pragmatic Programmer - geni.us/GfNj9
Data Structures and Algorithms Made Easy - geni.us/sqg6kJ
Refactoring - geni.us/ufAP0mE
The Productive Programmer - geni.us/IT9WiN
Pragmatic Thinking and Learning - geni.us/x81A
Test Driven Development - geni.us/HFV52
Microservices - geni.us/8vMA
🚀 MY FAVOURITE TOOLS
PIA VPN - piavpn.com/AlexHyett (83% off + 4 extra months free!)
Visual Studio Code - code.visualstudio.com/
Obsidian - obsidian.md/
Notion - affiliate.notion.so/alexhyett
⏳ TIMESTAMPS
00:00 Introduction
00:09 Software Testing Pyramid
00:25 Unit Tests
00:54 Code Coverage
01:05 Modified Condition Decision Coverage
01:34 Component Tests
02:22 Integration Tests
03:12 White Box and Black Box Testing
03:50 End-to-End Tests
05:32 Manual Testing
You can check out more of my favourite tools on my website:
www.alexhyett.com/tech/
🔗 MY KEY LINKS
🌍 Blog - www.alexhyett.com/
🐘 Mastodon - social.alexhyett.com/@alex
🧑‍💻WHO AM I
I’m Alex, a Software Developer and KZfaq working in the UK. I make videos about software development to help developers with the skills they need to be senior developers. As well as this KZfaq Channel, I also write articles on my website (alexhyett.com) as well as write a regular newsletter that contains some thoughts to help aspiring developers.
‼️ DISCLAIMERS
Some of the links in this description are affiliate links, for which I get a small commission, at no extra cost to you 🙂. I appreciate you supporting my channel so I can continue providing you with free software development content!
#coding #programming #developer

Пікірлер: 44

@RahulGupta-lq3px 2 ай бұрын

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

@RonnieDenzel Ай бұрын

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

@NaftuliSinger 3 ай бұрын

Great straight to the point video! Thank you!

@ashleyzimmermann5503 5 ай бұрын

Thank you!! So helpful!

@kcayushma 5 ай бұрын

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

@Jelvix 2 ай бұрын

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

@gaerinraj2336 Ай бұрын

Thank you very much. Very clearly explained

@codewithbru 7 ай бұрын

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

@alexhyettdev 7 ай бұрын

Thank you! I am glad it was useful.

@yassinesedjari1880 Жыл бұрын

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

@alexhyettdev Жыл бұрын

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

@user-hk6ns2eg1w 2 ай бұрын

thanks great explanation!!

@angellopez6687 20 күн бұрын

Very informative!

@user-ek7bv1de2k 5 ай бұрын

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.

@AnkitTiwari-dq7qm Жыл бұрын

Good explanation❤️

@alexhyettdev Жыл бұрын

Thank you, I am glad you liked it.

@terry- 5 ай бұрын

Great!

@kodnzikus 11 ай бұрын

Good stuff!

@alexhyettdev 11 ай бұрын

Thanks! I am glad you enjoyed.

@ukaszkiepas57 Жыл бұрын

thanks a lot

@alexhyettdev Жыл бұрын

You’re welcome!

@danieloyagha100 6 ай бұрын

Awesome

@melk48111 3 ай бұрын

what about regression test?

@khushsanghavi8805 10 ай бұрын

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

@alexhyettdev 10 ай бұрын

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.

@markodjordjevic6920 5 ай бұрын

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 5 ай бұрын

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.

@Gimmy27 Ай бұрын

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

@yantaosong 8 ай бұрын

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

@Lu149 8 ай бұрын

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)

@markveszelka376 4 ай бұрын

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! :)

@DaveThomson 2 ай бұрын

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

@coachobispersonalworkoutti2223 3 ай бұрын

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

@justaQAstudent 2 ай бұрын

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.

@chenfry8849 4 ай бұрын

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.

@kazian5453 2 ай бұрын

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.