0:00
uh greetings everyone i'm Satya and I'm uh thrilled to be here atnet conference
0:06
to talk about the something that has become a very close to the developers
0:11
heart that's the unit testing but today we are not just going to talk about the
0:16
unit uh test how to write the unit test uh we are going to take it further with
0:21
the artificial intelligence and GitHub copilot
0:27
so let me start with a quick questions how many of you here actually enjoy writing unit
0:34
test so are there anyone who enjoy writing the unit
0:41
test are you getting any response from the audience uh Simon I
0:48
think no okay actually uh now how many of you
0:53
wish there was an easier way to write them actually I wish uh and I feel the lazy writing the unit test manually
1:01
myself i find the um I always try to find the easier way how to write them so
1:06
I really had to write unit test cases manually it takes the more time than writing actual methods or the actual
1:14
core so great today uh we are going to explore that the easier way powered by
1:20
the AI here is what we will be covering today from the history uh history and
1:26
the basic of the unit test to the advanced ruling and the AIdriven
1:33
testing so this is the agenda we'll start brief history of the unit testing why unit testing uh test are matters
1:40
unit testing in the net ecosystem and the structure of the unit test what are
1:45
the best practices and the common approaches that we need to follow and what are the mistakes and the challenges
1:52
that you face while writing the unit tests also we'll use the um power of the
1:58
AI and GitHub copilot uh to create the unit test with some demonstrations and
2:04
uh real life use cases examples
2:09
about me uh I'm Satya Kharki with profession I'm a senior application
2:14
developer uh in addition to this I am Microsoft MVP and CISA partner MVP I'm
2:20
Microsoft certified trainer I have more than um 13 years of professional
2:25
experience in software development uh which is the net and the data mostly uh
2:31
with the Microsoft technologies so now let's uh begin with
2:37
uh the types of the um testing in the software development in software development there are several types of
2:43
the testing unit testing into testing functional testing regression testing
2:49
smoke and sanity testing performance or the load testing and security testing
2:55
unit testing just test the individual components or the functions uh uh it
3:00
just test the individuals and the separate uh components and the functions of a program integration testing test
3:08
how the modules work uh together how the different modules in a combinations uh
3:13
or the integration works together in testing uh tests uh the entire
3:18
application flow all the software flow and all the requirements uh functional
3:24
testing validates the features as for the requirement it just validates the
3:29
functions uh as for the requirement uh documentation regression testing ensures
3:35
the new code uh doesn't break the existing features whenever we add a new
3:41
uh functionality or the new features sometimes we can uh uh we may break the
3:46
existing uh functionality or the existing flow of the application so we
3:51
need the regression testing to ensure this uh changes doesn't uh hamper the
3:57
existing core smoke and sanity testing uh quickly checks for the system health
4:03
and performance load testing test for the performance when there are a lot of request into the same page or the same
4:09
requ uh same software then we need to check for the performance uh whether the software works properly or not for that
4:17
testing uh we have a performance load testing uh security testing uh by the name it just checks for the
4:23
vulnerabilities and the uh exploits in the
4:29
application uh if we go to the history of the unit testing uh it has its u own
4:35
roots in the early days of the software development uh initially developers uh tested their own work uh due to the uh
4:43
scarcity of the testers and the high cost of the computer time as software grew and the more complex and the number
4:50
of developers increase the need for the structure testing practices become evident unit testing history can be
4:56
tracked back to the early days of the software development but its formalizations and the widespread
5:03
adoption occur in the 1990s and beyond the 1960s and 70s saw the rise of the
5:10
more complex software leading uh to the greater emphasis on the uh testing
5:15
methodologies kent bank popularized with the ZUnit for the Java uh programming
5:22
and it was a unit testing evolved with the testdriven uh development TDD agile
5:28
uh agile development and the deops we can integrate the uh unit testing uh
5:34
with the CI/CD pipelines in the modern software
5:40
development so now let's come what is unit testing at its core uh unit testing
5:46
is about validating a single piece of functionality or unit in isolation it
5:52
could be a method a class or even a function if it takes the input and
5:57
produces the output it can be tested unit test should be fast repeatable and
6:04
independent it should be the fast and the independent with each other other as
6:09
it's the unit testing it should test the unit related to the that part of the u
6:15
functionality only uh so we don't just write the test
6:20
to make sure the test coverage reach 100% we write them to build the confidence confidence means to refactor
6:28
deploy and sleep at night knowing that your uh app won't crash on a production
6:34
additionally we can ensure and be confident that the application can run for the several years without the any
6:41
problem unit test act like a safety net uh unit test ensure the code uh
6:48
reliability and the quality it catches the box early in the development
6:53
supports uh refactoring safety it promotes the better design uh uh the uh
7:00
test uh driven development and the solid principles it adds in the CI/CD
7:06
pipelines and automate the pipelines whenever the any unit test get fails we
7:11
can install the CI/CD or the deployment in the test or the staging or in the
7:17
production sides that we can add a rule in the CI/CD with the unit
7:25
testing uh there are different types of the unit testing frameworks in the net
7:30
xunit is a one n unit and the ms test uh XUnit is a community favorite and it's a
7:38
open source uh and I in um uh XUnit is a currently the most
7:46
popular and communitydriven and is still widely used and the MS test is a
7:51
Microsoft default all of them have their own strength uh and depending on the
7:57
team and the project maturity we can select the frameworks that we need in the project xunit is a best at handling
8:05
the many test it's made to work well with the big test sets and can run the
8:10
many test in a parallel and unit and the MS test can also handle the many test
8:16
and can run in a parallel but not at well as the axe unit in short axe unit
8:22
is the fastest and uses the list resources so if you are working in a new
8:29
net projects then I would recommend to use the ax
8:35
unit so these are the attributes uh that uh uh are available for in the different
8:42
frameworks uh these are for the MS test nunit and the
8:48
xunit uh in today's demo I will be exploring about the xunit uh so here is
8:54
a sample code that how we can create the unit test using the xunit using the fact
9:00
attributes we can uh just arrange uh and we can act and assert the result like
9:07
this in the uh x unit and using the attribute
9:15
fact so we can do the unit test in the X unit using the theory and the inline
9:22
data actually the fact test the single scenario it test for the single values
9:27
and the single scenario using the on the other hand using the theory it's a
9:34
datadriven we can uh input the several values multiple values in the same
9:39
method and we can test the multiple values in the single method so it's
9:44
better if we need to test the multiple values then we can use the theory using inline data in the theory
9:52
attributes we can test the method ac across the multiple data set and the
9:58
multiple scenarios this is uh actually the super handy using the theory for the
10:03
multiple scenarios and uh fluent assertion is the
10:11
way of assertions all the MS test nunit and xunit supports the fluent assertions
10:18
we can use the fluent assertions to validate the test where the your test go
10:24
from the being just the functional to the beautiful fluent assertions allows you uh to write the expressive readable
10:32
and more intention revealing assertions it also gives the better
10:38
error messages when the test fails so it will be easier for us to debug and the
10:43
check why the this test cases is failing so for the now let's come for
10:50
the best practices for writing the unit test for best practices we need to follow the AA pattern arrange act assert
10:58
uh assert the results yeah uh that keeps the uh and additionally we need to keep
11:04
the test isolated use the clear naming conventions and test the both success
11:10
and the failure cases and uh please uh don't make the mocking everything mock
11:16
only the real uh dependencies so this is the uh best uh
11:22
practices uh for writing the unit test now let's come to the common mistakes that uh we do uh sometimes we over write
11:31
the fragile test missing edge cases and mixing the integration logic in the unit
11:36
test are some common pitfalls we need to avoid this and the test will be more
11:45
robust additionally there are some challenges that the developer face
11:50
writing the unit test uh developer has always the time constraint to write the unit test sometimes we need to deal with
11:57
the legacy code which uses the static method tightly coupled code it is challenging to write the unit test for
12:04
those u tightly coupled and the legacy uh system other challenges are writing
12:10
the good test data sometimes the difficult to get the good data to test the caches and the maintenance overhead
12:17
also the sometimes become the challenge due to the time
12:23
constraint now let's come how AI can help to writing the unit test uh AI can
12:30
automate the coding generation it generates the boiler plate test quickly and suggest the age cases for the
12:37
writing the unit test for the minimum value maximum value and the midcase value and the age cases uh the margin
12:44
values also it reduces the cognitive load in the system this automate the
12:50
sometimes the repetitive assertions in the program and AI can help the
12:56
productivity and coverage and at most it saves the time actually we can do the
13:02
faster uh uh unit test writing the unit test with the help of the
13:09
AI so the uh GitHub copilot uh is a tool uh that helps us to write the unit test
13:17
uh GitHub copilot i think these days everyone knows about the GitHub copilot uh this is a tool that uses the
13:23
artificial intelligence to assist the developers in suggesting in uh and
13:29
writing the code based on the context in the real time it was first announced by the GitHub in 29th June 2021 and powered
13:37
by the open AI codeex uh and it is trained in the u all the languages that
13:42
appears in the public repositories i will not go deep with the GitHub copilot i think uh these days everyone knows
13:50
about it uh now let's move to the next uh so how the uh GitHub copilot
13:58
capabilities help us uh to write the unit test and also in the software
14:03
development actually the GitHub copilot suggests the code completions as the developers uh type and turns the natural
14:10
language prompt into the coding and so based on that uh it gives the suggestion
14:15
and we can pick and optimize uh the code and also for the new programming also it
14:20
suggest and gives we can fix the bugs we can do the documentations um and we can write the unit test uh so
14:29
basically today we will be focusing how we can write the unit test using the GitHub copiler
14:38
So for writing the unit test the GitHub compiler generates the test by the commenting we can just write the simple
14:45
comments uh for example write the unit test for this method name then it suggests the uh unit test and we can
14:52
pick and implement it copilot suggests the complete test methods and it gives
14:58
the whole class uh unit test also that I will demonstrate later today it can
15:04
suggest the with the theory inline data mock setup and also using the fact
15:10
attribute whatever we need for our case we can uh just give the the com comment
15:16
according to this this comment it will suggest the code and it launchs from our
15:21
code base that's the code so before the AI and with the AI
15:28
how the unit test has been changed before AI the time consume it was
15:33
writing The unit test was a time consuming sometimes we often miss the age cases the code coverage was limited
15:40
and learning curve was steep but with the AI uh writing unit test is a faster
15:47
and AI suggest automatically the age cases so we don't miss the edge cases
15:53
while using the AI it improves through the AI helps the code coverage also we
15:58
can improve and for the juniors it's easier to learn and write the unit
16:07
test so now let's go for the demo
16:13
i will uh demo uh okay let me share my project and then
16:20
we'll be ready I will be ready to demo how we can write the unit
16:26
test I hope you are uh able to see my the visual studio screen
16:32
now so this is a uh blog API project here we have a model named the article
16:40
and this article has a property What is the integer uh integer ID title content
16:48
uh author created at updated at is published and is deleted tax category
16:53
and so on so these are the u model for the article uh API uh and with these
17:01
properties uh to validate these uh pro objects I have used the fluent
17:07
validation here so with the fluent validations we can uh we can validate
17:14
the objects of the is class so now uh today's demonstrations I will write whether this validations done uh using
17:21
the fluent validation is a correct for this property or not for that uh we will
17:27
write the unit test for this valid article validator class so uh I have
17:33
already the GitHub copilot here so if I select this class and ask with the
17:40
G asks with the GitHub compiler to write the unit test for this just we can give
17:54
test okay first let's uh begin with creating the uh test project we don't
18:01
have a text test project here so I'll begin with writing creating adding the test project then we'll be able to I
18:09
will be able to demo the everything in the with unit testing let's select the X
18:20
unit okay here is a X unit with the C
18:28
so for the uh standard approach and the core
18:34
quality and the performance we follow the naming convention standard naming conventions the application name is
18:41
blog.appi the API so for the test project we need to write the a blog dot
18:59
test and let's create the
19:06
project i'm selecting the framework net 9
19:20
wait so here we can see the uh default unit test class but for uh this
19:30
mode we have a valid uh validation uh article valid create the folder i will
19:35
follow the standard practices of keeping the everything like the main project and the test project format in the similar
19:42
manner so I'm going to add a folder here
19:55
validator okay validations as like the uh main uh
20:06
project and I will add a new class over here for the article
20:13
validator test so we are going to create a unit
20:19
test for the article validator uh class so I will uh create a name accordingly
20:47
test so we have article validator here i'll make it a
20:54
public so for the modern.net
21:03
And now in project uh and this article validator class and I will ask GitHub
21:10
compiler to write the unit test for this class /
21:19
test then it will suggest the unit test for this whole
21:28
fast it's taking some time
22:07
so it's taking too much time and now it's came we can see it has uh given the all the cases with the fact attribute
22:14
here i will just uh accept it and then we can modify over
22:20
there okay just I have created the new uh test project here but I haven't
22:25
implement uh I have not added the project reference so let's go and add a project
22:32
reference so I'll reference the blog.appi project
22:50
the this and we can using blog API
22:58
models and also fluent validator fluent validation test helper
23:05
we'll need okay how cool it has generated the
23:11
all the test cases for the all the properties of this uh article validator
23:16
class so in the article validator class uh we have a properties
23:23
uh ID and we have a rule uh fluent validation rule that the ID should be
23:29
greater than zero it should not be the zero and the negative values and we can write the unit test for that whether
23:36
this uh the input is uh validated properly or not and this is a required
23:42
field and for the title also titles length should be minimum one and the maximum 100 and uh this is also the
23:51
required field it should not be the empty so on the for the all the properties we have a validation rules in
23:58
the article validator so now here are the unit test for those uh
24:04
validations so okay first uh simply we will just accept the GitHub coil
24:10
suggestions and run the test here let me refresh it and run all test
24:35
it's taking some time until then I can show you here uh
24:43
the first uh unit test is for the ID id is empty it's checking ID should have a
24:50
error when ID is empty it's giving with the fact but we can check the uh emptiness and the test age cases with
24:58
the ID uh using the theory and the inline data that also we can use the
25:15
copilot I'm just it's taking
25:28
mhm yeah the all the test cases uh copilot has suggested the 11 test cases
25:33
and the all test cases are passed here uh this one was a default we can
25:40
just delete it we don't need this and actually this one is the one we
25:47
created using the GitHub copilot these are the there are the 10 unit test so
25:52
now we can modify and update this uh test cases uh using
25:57
the copilot for example we can write the um we can uh give a comment
26:12
right using theory and inline
26:26
FL so it is a suggest
26:39
staying it's giving me the wrong info or I
26:52
can one and the null
27:03
i have already done the demo here so here we can do like this we can just
27:09
write the unit test for the ID property using theory and inline data this comment and we can do like this here it
27:15
has just given me the another yeah sometimes this gives
27:21
the wrong suggestion also that we need to uh check and verify by our
27:34
shell just I will copy from the here so it will be
27:46
ag or I will write another
27:55
prompt for work ID using
28:00
validations okay herson sh
28:15
and data for invalid yes
28:39
uh I will change this method name ID is invalid simply I will uh write like this
28:46
uh ID is invalid I it will be easy uh and the
28:53
read method name will be the readables that's the standard approach
28:59
process and the first line just uh we are arranging here we are passing the ID
29:04
value from the parameter as in the fluent validations we have done it should be greater than zero so if it is
29:10
less than uh it is zero and the negative number uh then it this is uh this will
29:16
be invalid so simply we can just run it
29:43
Taste so we can see here the two test cases are the past uh for the code
29:50
quality and the performance we can write like this
29:55
uh the first line is arrange we can just enter the one empty line this is
30:04
act so for the better readability we should put one uh empty line uh between
30:11
the arrange act and the assert
30:17
so similarly for the valid case also we can keep the comment write the unit
30:25
test test okay my gaps lock uh
30:45
valid is a valid 100 is a
30:53
valid so we can run this and check whether
30:58
it's okay or not uh similarly we can do for the all the others if we need to
31:05
test the multiple values if there is a single values uh in the test m then we
31:11
can use the fact and we can pass the values like this so this is how we can
31:27
copilot so let's go to the other one
31:39
here so here is a this one is another project here I have done for the this is
31:47
going to the same yeah I have
31:53
done for the all the cases for the title also uh title is a valid title is
31:59
invalid so on we can do if we need the multiple
32:06
values all right now let's come to the presentation ations so we are I think
32:11
our time is also going to be finished so uh let's uh come back uh this is how we
32:17
can use the GitHub copilot and write the unit test in a very short time period so
32:24
there are sometimes the copilot's limitation uh copilots may miss the domain driven specific age cases
32:31
sometimes the edge cases can be the miss so we need to test the uh units for the
32:38
lower values upper values mid values and the edge cases so this is the standard
32:43
practice and uh we can cover the all the scenarios it can generate the incorrect
32:48
or the flex flaky test uh sometimes it requires the manual validation doesn't
32:54
understand the complex smoking uh logic so we need to check uh as in the
33:00
demonstrations I change my comment and then it gives the proper uh code earlier
33:05
it was giving with the error and the incorrect one so I change the comments that we need to developer need to
33:11
analyze whether this is a correct or the incorrect one so that things is there
33:17
that's the limitation of the copilot you still need the yeah human oversight that's the all uh we need to think and
33:25
this is just the companion and that helps but some it doesn't gives the
33:30
complete uh working code and sometimes it cannot follow the
33:35
coding standard as I uh demonstrated in the uh present uh in the demo uh so we
33:43
need to uh keep like This we need to enter the empty space line for the code
33:49
readability uh and also some further uh code uh
33:55
quality we can just remove this the unused uh settings uh only the use uh only the
34:03
things that are needed in the class that we can keep the unnecessary things we can um remove it so those are for the
34:11
standard practice and the performance that improves the performance of the code and there are copilot sometimes
34:18
gives the there is a security risk associated with the copilot using the copilot in the programming sometime
34:24
inaccuracy response and the non-coding topics Six
34:42
so in the future uh expectations with the UI uh with the AI and the unit
34:47
testing uh it will be the smarter test generations with the context awareness uh it can gives the more correct uh in
34:56
the future we can expect that it will give the more correct uh coding and the unit testings AIdriven test coverage uh
35:04
analysis and the AI based uh test factoring maintenance that will be the easy in the futures that we can expect
35:11
with the AI and uh we can expect the natural language to test the code to
35:17
suggestions for the missing scenarios that we can expect for the future with the AI for writing the unit
35:26
test so the key takeaways is a unit test are essential for the modern development
35:31
xunit MSU and you need uh choose whatever you need but for the mod run
35:36
and uh if you are going for the new project I would suggest we use the x unit uh because uh this uh in the x unit
35:44
we can run the several unit test parallelly uh and copilot accurates uh the unit
35:53
test writing human review is the main key using the AI in the programming and
35:59
we can embrace the synergy of the AI and the developers uh in the um modern on
36:05
software development that's all for the presentation and the demo huh