[0:00] software it's not like engineering
[0:02] something easy like a bridge where you
[0:03] start with a blueprint
[0:04] build it to spec then forget about it
[0:06] software is dynamic with a lot of moving
[0:08] parts and requirements that evolve over
[0:10] time
[0:11] developers build apps on top of a
[0:12] mountain of abstractions and nobody
[0:14] fully understands how every layer works
[0:16] that's okay because we just need to make
[0:18] sure that our code matches the
[0:19] requirements of the product test driven
[0:21] development is scientifically proven to
[0:23] reduce defects and improve the
[0:25] maintainability of a code base but it
[0:26] does require some additional effort
[0:28] one option is manual testing where a
[0:30] human being clicks on every button and
[0:32] fills out every form then assigns a
[0:34] bunch of jira tickets so they can be
[0:35] backlogged by the developers
[0:37] but that's not very efficient for a
[0:38] large scale product a better approach is
[0:41] to use automated testing tools that
[0:42] allow developers to write code for the
[0:44] sole purpose of testing the main
[0:46] application code in a code base you'll
[0:48] often find files that end in
[0:49] test or dot spec inside you'll first
[0:52] find a line of code that describes the
[0:54] feature or thing that's being tested
[0:56] that's known as a test suite and it
[0:57] contains one or more individual tests
[1:00] an individual test usually starts with
[1:02] it followed by a description
[1:03] of what is being tested the idea is to
[1:06] describe the behavior of the code in
[1:07] human readable terms
[1:09] inside the test the code will be
[1:10] executed then one or more
[1:12] expectations or assertions are used to
[1:14] check that the code produces the
[1:16] expected result if the expectation
[1:18] returns false then the test fails
[1:20] if it's true it passes test runners like
[1:22] jest or karma
[1:23] can run all your tests automatically in
[1:25] the background or on a continuous
[1:26] integration server before you deploy
[1:28] now there are many different automated
[1:30] testing strategies that you should be
[1:32] aware of
[1:32] at the most granular level we have unit
[1:34] testing which is designed to test
[1:36] individual functions or methods
[1:37] like does this function return the
[1:39] proper value when given the arguments of
[1:41] a
[1:41] and b then we have integration testing
[1:43] to determine how well different
[1:44] components or modules work together like
[1:46] is the component
[1:47] able to use the database service to get
[1:49] data from the server at the highest
[1:51] level we have end-to-end testing which
[1:53] usually happens in a mock browser or
[1:54] device
[1:55] and simulates actual user behaviors like
[1:57] clicking on buttons and filling out
[1:59] forms
[1:59] it's like having a robot to do all your
[2:01] manual testing for you
[2:02] and that's not all there are many other
[2:04] types like performance and smoke testing
[2:06] which i'll explain
[2:07] in my upcoming test driven development
[2:09] breakdown hit the like button if you
[2:10] want to see more short videos like this
[2:12] thanks for watching and i will see you
[2:14] in the next one