Unit testing is crucial for ensuring code quality, but writing effective test cases can be time-consuming. In this session, we’ll explore how AI and GitHub Copilot can assist in generating, optimizing, and improving unit tests. Learn best practices, validation techniques, and AI-driven strategies to enhance test coverage, reduce errors, and improve overall software reliability. Whether you're new to unit testing or looking to refine your approach, this session will equip you with practical insights to boost efficiency and code quality.
Conference Website: https://dotnetconference.com
📺 CSharp TV - Dev Streaming Destination http://csharp.tv
🌎 C# Corner - Community of Software and Data Developers https://www.c-sharpcorner.com
#CSharpTV #CSharpCorner #LiveShow #dotNet #DotNetConf2025
Show More Show Less View Video Transcript
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:48
the command the
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:47
uh API td
18:59
test and let's create the
19:06
project i'm selecting the framework net 9
19:12
it's creating let's
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:25
article
20:33
validator
20:42
[Music]
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:45
here now we can use
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:03
GitHub
25:15
copilot I'm just it's taking
25:23
time
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:07
uh
26:12
right using theory and inline
26:20
data with
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:23
here run the
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:31
for ID
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:16
uh use the GitHub
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


