---
title: '5 Types of Testing Software Every Developer Needs to Know!'
source: 'https://youtube.com/watch?v=YaXJeUkBe4Y'
video_id: 'YaXJeUkBe4Y'
date: 2026-06-15
duration_sec: 0
---

# 5 Types of Testing Software Every Developer Needs to Know!

> Source: [5 Types of Testing Software Every Developer Needs to Know!](https://youtube.com/watch?v=YaXJeUkBe4Y)

## Summary

This video explains the five types of software testing in the testing pyramid: unit, component, integration, end-to-end, and manual tests. It emphasizes the importance of focusing on lower-level tests for speed and maintainability, and discusses code coverage and automation.

### Key Points

- **Testing Pyramid Overview** [0:00] — The testing pyramid has unit tests at the base, followed by component, integration, end-to-end, and manual tests at the top. Lower tests are faster, simpler, and should make up the majority of tests.
- **Unit Tests** [0:27] — Unit tests verify individual methods/functions. Aim for high code coverage (line coverage). In industries like aviation, modified condition decision coverage (MCDC) is required, testing every condition in decisions.
- **Component Tests** [1:36] — Component tests test a complete section of the application in isolation, mocking dependencies like databases. They verify that units work together correctly.
- **Integration Tests** [2:24] — Integration tests verify that components work together without mocking, testing actual integrations like database connections, API calls, and message queues. They can be white-box or black-box.
- **End-to-End Tests** [3:56] — End-to-end tests automate UI interactions using tools like Selenium or Cypress. They follow Gherkin language (Given-When-Then) and are often run overnight due to long execution times.
- **Manual Tests** [5:33] — Manual tests are used for scenarios too complex or not worth automating. Ideally, most tests should be automated to avoid a cycle of insufficient testing.

### Conclusion

The testing pyramid guides developers to prioritize fast, reliable unit tests at the base, with fewer, slower tests at the top. Finding bugs lower in the pyramid is cheaper and easier to fix.

## Transcript

hey friends welcome back to the channel
so in this video we're going to be
covering the five different types of
software testing that you need to know
as a software developer now if you've
looked into software testing before
you're probably aware of the testing
pyramid chances are you probably haven't
thought much about why the pyramid is a
pyramid to start off with test at the
bottom of the pyramid should make up the
majority of the test in your test Suite
this is where you should be focusing
most of your efforts on as we move up
the pyramid the tests becomes slower
they become more complex and they take
more time to maintain at the base of our
pyramid we have the unit tests now most
developers are aware of what unit tests
are and the importance of them we write
unit tests for all the methods and
functions in our code to make sure that
our program is working correctly at the
lowest level the number of unit tests
you have to write is really dependent on
what the goal is for your testing
strategy you should try and test every
single line of your code in your methods
if you're not able to do that then it's
usually a sign that your function is
doing too much or you haven't written it
with testability in mind when we write
unit tests to test every single line of
code this is what we refer to as code
coverage typically one hundred percent
code coverage refers to line coverage
but this will vary depending on what
type of Industry you're working in if
you're working for the military or the
aviation Industries then you'll
generally need what they call modified
condition decision coverage or mcdc for
short for mcdc you not only test every
single line of code you also have to
test every single decision as well let's
say you have an if statement that has
three different conditions in it
therefore under mcdc coverage you need
to write at least eight different unit
tests to cover all the different
scenarios you would assume that if
everything is working at the lowest
level then it's all going to work when
you put it together but that isn't
always the case which is why we need the
next level of tests the next level up in
our testing pyramid is what we call
component tests this is where we test a
complete section of your application for
example if you're writing a web
application you might have a front end
an API and a database a component test
for the API would therefore test the API
in isolation from all the other
components we wouldn't include the front
end for example and we'd also mock out
the database as well as any other
components that your API is talking to
the purpose of the component test is to
make sure that your application is doing
what you expect it to do without the
interference of the other components by
mocking out the database we can test
both the happy path and the unhappy path
of your application we can see how the
application will behave under certain
conditions such as if the database is
down or if you send in a bad request
component tests make sure that all those
units that you tested in the previous
level work well when you put them
together the next level on our testing
pyramid is what we call the integration
tests in the previous level we mocked
out the database and other factors but
here we want to make sure that those
Integrations actually work this is where
you'll usually find out that this team
that you've been working with that have
decided to use camel case instead of
snake case for their API the monsters or
you'll find out that you have the
connection string wrong for your
database or you've written a typo in one
of your SQL queries for all of these
tests that we've done so far we
generally don't do it on a natural
environment unit tests component tests
and integration tests are all generally
run as part of the build process or at
the very least before a release thanks
to Docker it's fairly easy to spin up a
database and use it when you're running
your tests on your cicd server a lot of
developers get confused by integration
tests thinking they need to test all of
their application but that isn't the
case you just need to test the
Integrations between your components
generally depending on who writes your
integration tests whether it be a
developer or a tester will determine
whether they're considered white box
testing or Black Box testing for example
if your integration tests are written by
a developer and you're testing whether
your database repository can correctly
write you your database then this would
be considered a white box test however
if your integration tests are written by
a tester then they might be calling the
API and then seeing whether there's
something in the database this would
therefore be more of a black box because
they don't need to know the internals of
the application it's not just the calls
to the database that you might want to
include in your integration tests you
also want to test things like calling
other apis as well as writing a message
for a message queue so far we've tested
the individual functions we've tested
the components and we've tested how they
interact together the next level is to
test the application from end to end if
you're writing a web application then
these will typically be in the form of
automated UI tests and we generally use
tools such as selenium or Cyprus to
drive the UI through a web browser the
goal here is to test that everything is
working as expected end-to-end tests
typically include a mix between
functional testing such as making sure
the login works or a list is populated
correctly and acceptance testing which
makes sure that your application is
meeting business requirements we tend to
write end-to-end tests in what we call
gherkin language which follows the given
when then pattern Frameworks such as
spec flow and cucumber allow us to
execute code in this format while still
having the tests understandable by the
business stakeholders end-to-end tests
can take a really long time to run and
typically they're not run on every
single build once you have a lot of them
they can take several hours to run so
you generally need to run them overnight
this isn't ideal if you want to be
releasing multiple times per day and
therefore most teams split up their
tests into multiple groups with a
critical group that they can run before
each deployment unlike the other tests
that we've looked at so far end-to-end
tests needs all the components working
together and therefore they typically
run on an environment such as QA or uat
it can take a while to have a stable set
of end-to-end tests especially if you're
running them in a browser subtle things
such as your application taking a little
longer to load can cause your tests to
break and therefore you generally need
someone working full time on your
automation tests many of the Frameworks
allow you to take screenshots when a
test fails this can be really useful to
help you see what caused the failure
there are quite a lot of different tests
that fall under this bracket such as
performance testing regression testing
and security testing finally at the very
top of our pyramid we have the manual
tests these are the tests that are
either too complicated to try and
automate or they're not worth the time
in trying to do it usually it's a case
of having not enough testers to
developers which results in tests having
to be run manually instead of automating
them ideally you want to have the
majority of your tests automated
otherwise you're going to be in this
vicious cycle of not having enough time
to test your application before each
release if you find a bug in your
application then it's always better to
find it lower down the pyramid than it
is near the top let's say you find a bug
while you're doing your manual testing
you now have to search for your logs and
try and work out where exactly your
application failed compare that to
finding a bug in your unit tests and
you'll be given a stack Trace that shows
you the exact line where the problem
occurred if you like this video then
please hit that like button it really
helps with the YouTube algorithm and it
helps others find my videos thank you
for watching and I'll see you in the
next video