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