5 Types of Testing Software Every Developer Needs to Know!

[00:00] hey friends welcome back to the channel

[00:01] so in this video we're going to be

[00:02] covering the five different types of

[00:04] software testing that you need to know

[00:05] as a software developer now if you've

[00:07] looked into software testing before

[00:08] you're probably aware of the testing

[00:10] pyramid chances are you probably haven't

[00:12] thought much about why the pyramid is a

[00:13] pyramid to start off with test at the

[00:15] bottom of the pyramid should make up the

[00:16] majority of the test in your test Suite

[00:18] this is where you should be focusing

[00:19] most of your efforts on as we move up

[00:21] the pyramid the tests becomes slower

[00:23] they become more complex and they take

[00:25] more time to maintain at the base of our

[00:27] pyramid we have the unit tests now most

[00:30] developers are aware of what unit tests

[00:32] are and the importance of them we write

[00:34] unit tests for all the methods and

[00:36] functions in our code to make sure that

[00:37] our program is working correctly at the

[00:39] lowest level the number of unit tests

[00:41] you have to write is really dependent on

[00:42] what the goal is for your testing

[00:44] strategy you should try and test every

[00:46] single line of your code in your methods

[00:47] if you're not able to do that then it's

[00:49] usually a sign that your function is

[00:51] doing too much or you haven't written it

[00:52] with testability in mind when we write

[00:54] unit tests to test every single line of

[00:56] code this is what we refer to as code

[00:58] coverage typically one hundred percent

[01:00] code coverage refers to line coverage

[01:02] but this will vary depending on what

[01:04] type of Industry you're working in if

[01:06] you're working for the military or the

[01:07] aviation Industries then you'll

[01:09] generally need what they call modified

[01:10] condition decision coverage or mcdc for

[01:13] short for mcdc you not only test every

[01:15] single line of code you also have to

[01:17] test every single decision as well let's

[01:19] say you have an if statement that has

[01:20] three different conditions in it

[01:22] therefore under mcdc coverage you need

[01:24] to write at least eight different unit

[01:26] tests to cover all the different

[01:27] scenarios you would assume that if

[01:29] everything is working at the lowest

[01:30] level then it's all going to work when

[01:31] you put it together but that isn't

[01:33] always the case which is why we need the

[01:34] next level of tests the next level up in

[01:36] our testing pyramid is what we call

[01:38] component tests this is where we test a

[01:40] complete section of your application for

[01:42] example if you're writing a web

[01:43] application you might have a front end

[01:45] an API and a database a component test

[01:48] for the API would therefore test the API

[01:50] in isolation from all the other

[01:51] components we wouldn't include the front

[01:53] end for example and we'd also mock out

[01:55] the database as well as any other

[01:56] components that your API is talking to

[01:58] the purpose of the component test is to

[01:59] make sure that your application is doing

[02:02] what you expect it to do without the

[02:04] interference of the other components by

[02:05] mocking out the database we can test

[02:07] both the happy path and the unhappy path

[02:09] of your application we can see how the

[02:11] application will behave under certain

[02:13] conditions such as if the database is

[02:15] down or if you send in a bad request

[02:17] component tests make sure that all those

[02:19] units that you tested in the previous

[02:20] level work well when you put them

[02:22] together the next level on our testing

[02:24] pyramid is what we call the integration

[02:25] tests in the previous level we mocked

[02:28] out the database and other factors but

[02:30] here we want to make sure that those

[02:31] Integrations actually work this is where

[02:33] you'll usually find out that this team

[02:35] that you've been working with that have

[02:36] decided to use camel case instead of

[02:38] snake case for their API the monsters or

[02:40] you'll find out that you have the

[02:41] connection string wrong for your

[02:42] database or you've written a typo in one

[02:44] of your SQL queries for all of these

[02:46] tests that we've done so far we

[02:48] generally don't do it on a natural

[02:49] environment unit tests component tests

[02:51] and integration tests are all generally

[02:53] run as part of the build process or at

[02:55] the very least before a release thanks

[02:57] to Docker it's fairly easy to spin up a

[02:59] database and use it when you're running

[03:01] your tests on your cicd server a lot of

[03:03] developers get confused by integration

[03:05] tests thinking they need to test all of

[03:06] their application but that isn't the

[03:08] case you just need to test the

[03:10] Integrations between your components

[03:11] generally depending on who writes your

[03:13] integration tests whether it be a

[03:15] developer or a tester will determine

[03:17] whether they're considered white box

[03:18] testing or Black Box testing for example

[03:21] if your integration tests are written by

[03:22] a developer and you're testing whether

[03:24] your database repository can correctly

[03:26] write you your database then this would

[03:28] be considered a white box test however

[03:30] if your integration tests are written by

[03:31] a tester then they might be calling the

[03:33] API and then seeing whether there's

[03:35] something in the database this would

[03:36] therefore be more of a black box because

[03:38] they don't need to know the internals of

[03:40] the application it's not just the calls

[03:42] to the database that you might want to

[03:43] include in your integration tests you

[03:45] also want to test things like calling

[03:47] other apis as well as writing a message

[03:49] for a message queue so far we've tested

[03:51] the individual functions we've tested

[03:52] the components and we've tested how they

[03:54] interact together the next level is to

[03:56] test the application from end to end if

[03:58] you're writing a web application then

[04:00] these will typically be in the form of

[04:01] automated UI tests and we generally use

[04:03] tools such as selenium or Cyprus to

[04:06] drive the UI through a web browser the

[04:08] goal here is to test that everything is

[04:10] working as expected end-to-end tests

[04:12] typically include a mix between

[04:13] functional testing such as making sure

[04:16] the login works or a list is populated

[04:18] correctly and acceptance testing which

[04:20] makes sure that your application is

[04:22] meeting business requirements we tend to

[04:24] write end-to-end tests in what we call

[04:25] gherkin language which follows the given

[04:27] when then pattern Frameworks such as

[04:29] spec flow and cucumber allow us to

[04:31] execute code in this format while still

[04:33] having the tests understandable by the

[04:35] business stakeholders end-to-end tests

[04:37] can take a really long time to run and

[04:39] typically they're not run on every

[04:41] single build once you have a lot of them

[04:42] they can take several hours to run so

[04:44] you generally need to run them overnight

[04:46] this isn't ideal if you want to be

[04:47] releasing multiple times per day and

[04:49] therefore most teams split up their

[04:51] tests into multiple groups with a

[04:54] critical group that they can run before

[04:55] each deployment unlike the other tests

[04:57] that we've looked at so far end-to-end

[05:00] tests needs all the components working

[05:01] together and therefore they typically

[05:03] run on an environment such as QA or uat

[05:05] it can take a while to have a stable set

[05:08] of end-to-end tests especially if you're

[05:09] running them in a browser subtle things

[05:11] such as your application taking a little

[05:13] longer to load can cause your tests to

[05:15] break and therefore you generally need

[05:17] someone working full time on your

[05:18] automation tests many of the Frameworks

[05:20] allow you to take screenshots when a

[05:22] test fails this can be really useful to

[05:24] help you see what caused the failure

[05:25] there are quite a lot of different tests

[05:27] that fall under this bracket such as

[05:29] performance testing regression testing

[05:31] and security testing finally at the very

[05:33] top of our pyramid we have the manual

[05:34] tests these are the tests that are

[05:36] either too complicated to try and

[05:38] automate or they're not worth the time

[05:40] in trying to do it usually it's a case

[05:41] of having not enough testers to

[05:43] developers which results in tests having

[05:45] to be run manually instead of automating

[05:46] them ideally you want to have the

[05:48] majority of your tests automated

[05:50] otherwise you're going to be in this

[05:51] vicious cycle of not having enough time

[05:53] to test your application before each

[05:54] release if you find a bug in your

[05:56] application then it's always better to

[05:58] find it lower down the pyramid than it

[05:59] is near the top let's say you find a bug

[06:01] while you're doing your manual testing

[06:02] you now have to search for your logs and

[06:04] try and work out where exactly your

[06:06] application failed compare that to

[06:08] finding a bug in your unit tests and

[06:10] you'll be given a stack Trace that shows

[06:11] you the exact line where the problem

[06:13] occurred if you like this video then

[06:14] please hit that like button it really

[06:16] helps with the YouTube algorithm and it

[06:17] helps others find my videos thank you

[06:19] for watching and I'll see you in the

[06:21] next video