What is Live Unit Testing

Live Unit Testing is a brand-new technology, made available in Visual Studio 2017 version 15.3 or above. Live unit testing enables the IDE to execute unit tests automatically in real time without cod being built and as you make changes to the code.

Which frameworks and tooling support Live Unit Testing?

Live Unit Testing is available for C# and Visual Basic projects using MSTest, NUnit, or xUnit Test frameworks that target the .NET Core or .NET Framework in the Enterprise Edition of Visual Studio 2017.

Problem Statement

Unit Tests, and code have a very close relationship, and both depend heavily on each other. I.e. a change in source code must impact the unit test(s) code for what was being tested. Similarly, a change in a unit test, must impact the code coverage of the source code, which is being exercised via unit tests.

In the light of above mentioned problem statement, there is no efficient and developer friendly solution which a traditional unit tests can solve. Moreover, validating code changes through unit tests may quickly turn out to be a tedious task, as you must run all the unit tests from Test Explore after every code change.

Benefits of Live Unit Testing

It empower the developers to refactor and change their code with greater confidence. Live Unit Testing graphically depicts code coverage in real time and provides a quick visual view of the code coverage, and which code statements are passing in unit tests. As per the name “Live Unit Test”, you don’t have to build the code, and run the tests again via Test Explorer to validate the changes. I.e. soon after code changes are made, unit tests will be automatically executed to reflect the impact (pass, fail).

Quick look at a traditional Unit Test

As explained in my previous article Inside Out : TDD using C# there is always a system under test or code which needs to be exercised via unit tests. This code is available at my GitHub, and this code will work just fine for Unit Test, and Live Unit Test (if you have the required Visual Studio 2017) purposes.

The code below, shows unit tests written for Account.cs class’s IsAccountActive() function.

What is being tested?

As shown in the image above, Account.cs class’s IsAccountActive() method is being exercised. I.e. Account.cs is our System Under Test.

Let’s begin with Red, Refactor, Green

As this code is showcasing Test Driven Development, I.e. write a failing test, and then write code to make that test pass, and so on.

First, let’s write/refactor code to make TestAccountStatus_Active_Success() test case pass. To do so, copy the code from TestCase#1 code snippet from TextFile1.txt (included in the UnitTestBankApplication at my github

Account.cs code when TestAccountStatus_Active_Success() was failing:

Account.cs code changes to make TestAccountStatus_Active_Success() pass:

Now, if you will run the Tests again, by clicking “Run All” option in the Test Explorer, then you shall observe that 1/3 Test case is passing, as shown in the image below.

But what exactly is the problem here?

Unit Test code or source code which is being tested doesn’t explicitly tell which code lines are being covered, not covered, or passed via unit tests. I.e. whenever developer will change the code, test cases need to be run over and over to identify the impact, and that is without any visual clue in the code files. Hence, with traditional unit testing, a developer can’t clearly tell which code statements are covered, or not covered, through passed or failing unit tests.

Turn-on Live Unit Testing

Navigate to the Test menu, expand Live Unit Testing, and then click on Start, as shown in the image below.

If you don’t see this option then you might not have the appropriate version of Visual Studio 2017 Enterprise Edition, which offers the Live Unit Testing feature. However, if you have Visual Studio 2017 enterprise edition, and you don’t see this option, then you can add Live Unit Testing tool from the setup menu, and selecting it from the individual components tab.

Live Unit Testing in action

As soon as you have started the Live Unit Testing, your IDE will instantly start tracking the code changes in the background, as shown by X, , and symbols on the left of code statements in the IDE, as shown in the image below.

As of now, there is only one test passing, let’s take the Test Case#2 code from TestFile1.txt

and put it in Account.cs class’s IsAccountActive() function, and soon after putting the code in there, without building the code explicitly, you shall observe the changes, and notice that now two tests are passing. Alongside, you shall observe the changes to the code line symbols X, , and on the left.

Now, you may want to work on passing the third unit test, and to make that happen as per TDD guidelines, you code should refactor the code logic to accomplish that. Put the Test Case#3 code from TestFile1.txt, into Account.cs class’s IsAccountActive() function

As soon as the code is refactored, again without any explicit build and running tests from Test Explorer, Live Unit Testing observed the code changes and ran the tests. As shown in the image below, now all three unit tests are passing, and all code lines in Account.cs class’s IsAccountActive() shows symbol on their left. The  symbol means that all code statements in this function or block are covered by the Unit Tests.

Now, what’s next?

As you can see in the image above towards the bottom-half, ─ symbol in front of other code blocks, which means that these code blocks are covered by 0 test. I.e. no unit test case(s) exist for these code blocks. You may want to take it to next level by taking code from my GitHub repo, and expand it.

Pause or Stop Live Unit Testing

Once Live Unit Testing has been started, now it can be either paused or stopped. You can navigate to the Test menu, select Live Unit Testing, and then choose either Pause or Stop, as shown in the image below. Based on the choice you make; Live Unit Testing will be either paused or stopped completely.

Excluding individual Unit Tests from Live Unit Testing

Ideally, all the tests in all the projects will be covered once Live Unit Testing has been started.

But, you can use the following attributes to specify in the source code that you want to exclude targeted test methods from Live Unit Testing:

  • For MSTest: [TestCategory(“SkipWhenLiveUnitTesting”)]
  • For xUnit: [Trait(“Category”, “SkipWhenLiveUnitTesting”)]
  • For NUnit: [Category(“SkipWhenLiveUnitTesting”)]

Include/Exclude Unit Test Projects or Test class files

Live Unit Testing is IDE level, and it works for all test projects and all class files which are part of a test project. To include/exclude either a test project or a test class file, you can use the context menu and choose Live Unit Testing, Include or Exclude options. The image below shows these options on the UnitTestBankApplication Test Project, and you may want to try it on test class file as well.

Wrapping up

Live Unit Testing appears to be a milestone in fast-paced, technology-heavy software development field. This certainly doesn’t take away the importance of knowing Unit Test fundamentals, rather, it enforces the TDD (Test Driven Development) mindset in an effective, and productive manner to the developer community, by showing visual clues in the IDE code window, and running the tests while a developer is refactoring the code.

How to use Agile correctly?

September 27th, 2016 | Posted by Vidya Vrat in Agile-Scrum | Best Practices - (0 Comments)

Abstract

This article uncovers the various aspects of Agile software development technique and Scrum framework to enable an Agile team/ team member to understand various issues any software development team sails through and how to come over those challenges.

Where Did Agile Come from?

In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems” which criticized sequential development.

He asserted that software should not be developed like an automobile on an assembly line, in which each piece is added in sequential phases. In such sequential phases, every phase of the project must be completed before the next phase can begin. Dr. Royce recommended against the phase based approach in which developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. Royce specifically objected to this approach due to the lack of communication between the specialized groups that complete each phase of work.

Developing a Solution for Customer

Any software project starts from Gathering Requirements phase and many times what is developed is not exactly what end user wanted, and many software projects fail during implementation.

Value Delivery Impediments

In today’s world teams have huge dependencies on various stakeholders of the project including Users <-> Developers <-> QA <->Operations etc. and it’s proven that we need regular communication and collaboration to deliver the value.

Any communication gap or lack of collaboration between these team(s) or individuals will have impact in following areas

Plan Driven Vs Value Driven Approach 

Old school of software development has taught “waterfall” approach of software development.  In waterfall approach, one phase’s output becomes input to next phase and those phases are distributed across the project timeline as shown in the image below.

Today’s software development technique is “Iterative“ and “Incremental” I.e. Agile. In Agile, team run through all the phases within a Sprint as briefly shown in the image below.

In waterfall, development teams only have one chance to get each aspect of a project right. Whereas in Agile team has better understanding and learning from previous Sprint on what to emphasize upon and what to avoid to reap better results.

Why Agile

  • Agile development methodology provides opportunities to assess the direction of a project throughout the development lifecycle.
  • This is achieved through regular cadences of work, known as sprints or iterations.
  • At the end of which teams must present a potentially shippable product increment. The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market.

Agile Manifesto

Perfect Agile Team, does it really exist?

Success of any project depends on Team. I.e. it’s critical to have an awesome team to have rocking results. But in reality this doesn’t happen as team consists of individuals with their own attitude, aptitude, work style, ethics, behavior and issues etc.

Bruce Tuckman’s team development model is a perfect example how team can come together and start functioning.

Agile team’s Success heavily depends upon “self-Organized” team.

Scrum Process

Sprint Length and Team Size

Sprint is to Run at full speed over a short distance. Ideal Sprint length is 2 weeks. My recommendation is as following and I have experienced that it really works well.

  • Ideal Agile teams must be 7 to 9 +/-2 members.
  • If you have more candidates in a team, then divide teams and have separate agile teams.
  • A representative of each team might want to attend other team’s standup for critical issues, follow-up and announcements etc.

Most wanted thing in Agile – Velocity

Velocity is the account of work team completes and delivers in each sprint. Ideal sprint duration is 2 weeks and highly recommend this to any team.

I have seen better results when team works towards a pre-defined code complete date for instance, today is Tuesday and sprint is for two weeks, team can agree upon a code complete date of Wednesday of 2nd week. I.e. team will try to complete all the work by that day and have it ready for QA.

This just gives a deadline to accomplish the work, however there will be situations where work couldn’t get complete or even rolled over to next sprint and that is fine in some cases.

Here are some of my recommendations:

Give as much time as possible to Developers, SDETs and QA to fulfill their commitment. I.e. less meetings and hindrance.

Have at-least 2-3 sprints worth work well-groomed and available for the team as “ready for development”.  Two reasons:

1 – At times for unforeseen reasons or instances a user story may be pulled out of current sprint. In such situations you lose story points you committed to. In such scenarios other US can be delivered.

2- Sometimes team or an individual is able to complete the work early and available to pick more work, in such situation well-groomed loaded backlog can come very handy.

Groom Often (Backlog Grooming)

  • Usually Sprint 0 is dedicated for backlog grooming and then team start to deliver in Sprint 1 and onward.
  • Considering any Enterprise Line of Business (LOB) application, sprint 0 can’t suffice the entire backlog groomed at once.
  • Hence, team must regularly have backlog grooming in small chunks of time instead of lengthy full day meetings.

Ideally, grooming is a lengthy process and hence groom in short chunks and team lead can be present in the regular or small grooming sessions with PO or business and team can continue to focus on their work. However, team must be present at Sprint Planning time.

Brainstorm Together (Sprint Planning)

  • Everyone is invited. Many teams ask only Dev’s to attend and excuse the QA team members.
  • Understand the problem 1st.
  • Ask Questions and clarifications.
  • “Well defined” Acceptance criteria is a must.
  • Confirm that User Story is ready for development.
  • Nothing should fall from the cracks, document all within the User Story.

Daily Status Check

Just three things, no more; no less

  1.  What have you done since yesterday?
  2.  What are you planning to do today?
  3.  Do you have any blockers preventing you from accomplishing your goal?

I recommend, that if you have to discuss something related to a User Story or bug or some reported a status on something etc. then “Post Scrum” that. I.e. discuss that when team has given the status and now you can drill into the detailed discussion.

Many times Dev’s start going into technical details of the issue, design of solution, architecture, code review comment details etc. during their status. This is not right way of doing it. Just Post Scrum all that; if you have to discuss anything other than those three absolute must.

I am Blocked

It’s is obvious that someone at some time is blocked on something. You can help, by asking just:

  • Really
  • On what
  • What is the issue
  • Who is POC (Point of Contact)
  • What is ETA (Estimated Time of Arrival) I.e. delivering solution to you.

I will give you a scenario, let’s say I join a team which works on some third part control library and my license of that product is pending or not yet processed. Am I blocked. Well in a way; yes, but I can use trial version up to 30 days and when my license information come I can punch those.

Also, many times we just tell other team that we are blocked on something and we are expecting the endpoint or JSON format etc. but we don’t always ask what is ETA and convey the timelines we have to adhere. If this has any impact on your team’s deliverable than you need to re-prioritize, escalate etc. so either that work is delivered to you on time or that user story is pushed to next sprint and you pick next item on Stack rank (priority) from the Product backlog.

Scrum Master must help you to get unblocked.

Is there time to Think?

Many people and teams think that Agile has no time for following:

  • Researching a solution
  • Brain storming on the solution architecture.
  • Share your thought process, design, approach with the architects, PO etc. to get the insight.

Well, there is and it’s called “Spike”. In agile software development, a “Spike” is a user story that cannot be estimated until a development team runs a time boxed investigation. The output of a spike story is an estimate for the original story.

Some examples of spikes:

1- Discussing authentication mechanism and partner team’s flexibility to apply / accept those changes.

2- Discovering or researching for an off the shelf solution work flow solution.

Technical Debt

Every team has it, generated it, accumulate it; not a problem. Just make sure you pay it off.

Technical debt is a terms which is used for the work which team or an individual didn’t prioritize upon while pushing the deliverable, and require improvements.

  • First and foremost, poor coding style and standards.
  • No unit test cases.
  • Not following OO design principles and developing long monolithic classes and code libraries.
  • Not envisioning on proper candidate technology, architecture or approach and then hitting a wall. I.e. when application is little bit mature you start to feel the hit on User experience, performance, scalability, code maintenance etc.
  • Code files has a lot of comments. I.e. code is completely documented. Many developers write few lines of comment for each line of code.
  • Code is not self-documented.
  • Magic strings (hard coded path and endpoints etc. in the code)
  • Dead code in project. You must have seen or left some commented code in various code files. This is dead code and needs to be cleaned up.

Read my detailed article on Technical Debt

Branching and Merging

Branching enables parallel development and delivery by providing each development activity a self-contained snapshot of needed sources, tools, external dependencies and process automation.

Continuous check-ins pollute the branch.  Have a separate Release branch per Release.

Basic Dual Branch is an Ideal branch plan, have a Main, spin a Dev branch for development and have RI (Reverse Integration) and FI (Forward Integration) to merge changes between Child and Parent branch respectively.

When you are ready to deliver the shippable product at sprint completion then spin a Release Branch and deliver the product out of that.

Feature Branch Plan is slightly complex and requires more merge efforts but at the same time it give entire isolation of work being done in a feature branch for entire time; until it’s ready for merge to Dev branch. One major issue with this plan is that your feature branch will have old and stale code and when you will Get Latest / Pull from the changes then you will get some conflicts etc.

Just saying

“Save your creativity for your product… not the branch plan.”

“Your branch distance from main is equal to your level of insanity”

Unit Testing

Many teams don’t invest in Unit Testing. For any Agile Team Unit Test is the most critical thing and team must continue to increase the code coverage of the tests. Even based on Test Triangle as shown in the image below, Unit Test has the larger scope in Software Testing.

Read my detailed article on NUnit with Visual Studio

Read my article on Visual Studio and .NET’s Unit Test Framework

Read my article on Inside Out: TDD using C#

Benefits of Unit Testing

  1. Unit Testing gives an opportunity to think as User of your code, instead of an implementer of the production code.
  2. Reduce bugs by identifying all the use case scenarios to reflect intent (end user’s mindset, business needs, expected functionality and business validations etc.)
  1. Less-n-less time on debugging.
  2. Avoid collateral damage. I.e. a fix in one area may break functionality in another possibly
    related/unrelated area.
  3. Helps you achieve YAGNI– You Aren’t Gonna Need It. I.e. saves you from writing code which you
    don’t need

Tips for System Test

  • Must know how much to test, drive your Test cases from Acceptance criteria.
  • Avoid duplicate test steps.
  • Make sure that all your Test Cases are Mapped to Acceptance Criteria.
  • Try to combine similar behaviors in a single test case.
  • Do not go above and beyond to identify every corner case or hack the system. I.e. above a beyond the acceptance criteria. I know this is tricky and someone may want to debate on it. I didn’t mean to say that don’t test any areas of application which might have direct impact of a User Story or what not. But there is always a fine line on what to test and what not.
  • Time box for ad-hoc testing. I.e. in each sprint time-box some time

Continuous Integration (CI)

  • An important part of any software development process is getting reliable builds of the software. – Martin Fowler
  • Continuous Integration (CI) is the strategy and practice of making sure that changes to a software project’s code base are successfully built, tested, reported on, and rapidly made available to all parties after they are introduced.

Advantages of CI

  • Increase ROI (Return on Investment).
  • Guarantees successfully compiled software.
  • Visible progress reporting and problem tracking.
  • Low TCO (Total Cost of Ownership).
  • Improve development standards, consistencies and accountability.
  • Rapidly identify bugs, who created them, and where it is.
  • Quickly push high quality change updates to testing.
  • Reduce development integration effort.
  • Increase amount of quality code.

Successful Build

An aggressive goal for a successful build would include:

  • All the latest sources are checked out of the configuration management system.
  • Every file is compiled from scratch.
  • The resulting object files are linked and deployed for execution.
  • The system is started and a suite of tests is run against the system.
  • If all of the above execute without error or human intervention and every test passes, that is a successful build.

Let the Team see what is happening

  • Must have Gated builds and nightly builds to ensure value delivery of the functionality.

You can use this build monitoring tool from https://teambuildscreen.codeplex.com/

Continuous Delivery (CD)

CI mainly focuses on development teams. The output of the CI system normally forms the input to the manual testing process and to the rest of the release process.

You’re doing continuous delivery when:

  • Your software is deployable throughout its lifecycle
  • Your team prioritizes keeping the software deployable over working on new features
  • You can perform push-button deployments of any version of the software to any environment on demand

 

 

Abstract

This article provides a broad overview of review process for the code written in C# using Visual Studio 2015 and also uncovers best practices for code review. Code Review is a very important part of any developer’s life. Code review is a technique which allows another developer (not necessarily working in same team or same feature within a team) to go over-n-through your code line-by-line and identify areas for improvement or point out holes.  Hence, code review is a process and not a technology. However, there are some tools available (covered later in this article) which can enable a developer to write good quality code.

Disclaimer

There are numerous guidelines and best practices software development teams follow and depend on. This article will uncover most of those but it may not cover all the best practices around code review. However, I want to assure you that all the guidelines mentioned below will help any individual to practice and apply good coding principles and perform a quality code review.

Is it must to have my code, reviewed by other dev?

Well, you must. But it depends on your team’s development methodology and ALM (Application Lifecycle Management) tool settings. There are ways to by-pass the code review by simply just not doing it and straight checking-in the code. It’s not recommended though.

What if my code is not reviewed?

It’s hard to say, but at times and in some cases it might cause serious issues and raise concern for the whole team. For instance, a condition check is missed, or null is not handled properly or not all error situations are being handled by your exception handling block. Well, these examples might sound very simple and most of the developers do write defensive code and cover such aspects. But what code review can also provide value towards is your “design”, “techniques”, “patterns”, “approach” etc.

How to find a code reviewer

I have worked in various team settings and work environments. Many times I have been invited to perform a code review for a developer who is not part of my team or rather I am not part of their team. But what I admire and appreciate here is the fact; that someone reached out to another dev in case of their team’s developer is either not available or busy with critical production issue etc. Such mindset empowers the team to deliver the best written code.

Let’s Begin with Best Practices of code Review

Here, I am going to list out some areas which are critical from code review perspective. I tried to highlight the core best practices which are must in any code review. I have seen many times that in a code review developers are more focused to look for code design patterns or some areas in code review and then try to convince

1- Project and File names

Many times developer’s only focus on code, but in my view your Project name, file name etc. also matters a lot. It’s not sufficient to deliver well written functional code; a well-defined project and file name is equally important and brings a lot of clarity by offering a sense of purpose being served by solution, project or a file. For instance see the solution and project name in as shown in the image below.


Figure-1: Properly named Solution and Project

2- Always begin from the top

Before you really start scanning through the code blocks/statements in a class (.cs) file; I would recommend that you must 1st look at the “using” statements in any .cs file. I have personally observed that many times developers add numerous “using” statements while trying various code blocks to achieve the functionality. But once that functionality is accomplished; many developers tend to forget about cleaning up references of those “using” statements which are no longer needed now and must be removed. Visual Studio 2015 show unused using statements in grey color which can be safely removed as shown in the image below.

Figure-2: Un-used using statements are grayed out by default in Visual Studio 2015

3-  Sort all the using statements

Usual development practice is that we keep adding new using statements at the end of previous ones, for instance as shown in the image below.

Figure-3: Newly added using statements

Let’s assume that code is consuming all of the added using statements, but the issue is that these are not sorted. One of the coding best practices is to Sort all using statements. To sort using statements right-click in code editor windows and click on “Organize Usings” then click on “Sort Usings”.

Figure-4  Sort Usings option in Visual Studio 2015

After performing the “Sort Usings” all the using statements will be alphabetically sorted (this is the only order A – Z) and will be arranged as shown in the image below.

Figure-5 Alphabetically Sorted Using statement

4- Don’t just ignore warnings

As a developer we are more focused on compilation errors and want to see that project/solution build successfully. For instance, consider the code as shown in the image below.

Figure-6 sample code

This is a very simple code and project will build successfully without any compilation errors. However, as you can see that “j” is used nowhere in the code and so this will cause a warning; which many developers doesn’t seem to care about. In my view and as many software companies including many Microsoft teams I have worked with enforce 0 warnings policy before check-in. Hence, it is very important to look in detail at the “Error List” View menu à Error List, and then observe Warning Tab and must try to have that also show “0 Warning” just like we always work to only see “0 Errors”.

Figure-7 Error List, highlighting warning in the code

5-  Code Consistency

One very important quality of well written code is “Consistency”. I.e. stick to one style. Let’s say that you want to declare an integer variable and it’s obvious that different teams and developers will have different coding guidelines. Many times developers ignore this and code has scattered instances of types/keywords Int32 or int and String or string, this demonstrates that code consistency is violated. However, using mixed statements will successfully compile the code but makes your code base completely in-consistent. 


Figure-8 Code consistency violation

6-  Do care for Null all the times

Null has catastrophic impact on your code functionality. Simply a null check ignored and you will face the consequences. This is why many developer productivity tools like Re-Sharper prompt for any potential “NullReferenceException” which can be triggered from your code. Make sure that all your if/else do take enough care of null and have guard(s) in place, most of the times IsNullOrEmpty or IsNullOrWhiteSpace will come really handy.

7-  Dead code

Many times I have seen that as a developer we are mostly interested in our own code; to be specific, code we are writing. At times we do observe a block of code which is commented for long, but we don’t seem to care, but why not?  Well, in my view there are two reasons for this. First, I don’t care as long as my code works. Second, I am working in an agile team and I am committed to finish my task in committed timelines. First one is an attitude problem, second is timeline and hours remaining to complete the work. But both can do one thing for sure. Open an item in Technical Debt backlog with details to have that file cleaned up.

8-  Naming Convention

All developers today are well aware of Camel and Pascal casing and when to use one over the other. For instance variable and parameter names must follow Camel casing and for class, function, and method names Pascal casing must be used. Make sure this basic principle is applied consistently.

9-  Code Readability

Many times code is written in a way that anyone can hardly make sense out of it. I.e. all code is so jumbled up and one line after the other that it’s barely readable. Make sure that code has proper Single line spacing wherever applicable between the code blocks.

 10-Handling Unmanaged Resources 

Even though .NET Framework takes good care of Memory management via GC (garbage collection) but there are limitations on what all garbage items and from where those can be collected and what not. Many times, it’s wise to handle cleaning of expensive resources like File I/O handles, connections, Network resources, etc. by yourself. Such items can be disposed of once their usage is over and this can be done using the “using” block for unmanaged code, if you want to automatically handle the disposing of objects once they are out of scope.  Another good place to handle such code is finally block for example, File I/O operation to read a file as shown in the image below.

Watch my YouTube channel video on FIle I/O here:

Figure-9 Handling unmanaged resources by .NET’s StreamReader

11-    Write Defensive Code

.NET Exception Handling is the key to write defensive code and protect your application against any runtime anomalies. Three magic words to solve most of your problems are try/catch and finally. Proper implementation and usage of Exception Handling and logging any exception messages and details can add a lot of value to application in terms of application monitoring and troubleshooting.

12-    Declare access specifiers explicitly

C# .NET has default scope defined for various types for instance a variable is private by default and so in a class we like to write just “int i” but it’s more appropriate to be declarative and instead write it as “private int i”.

Do you know what default scope of a class is in C #? Watch my YouTube channel video here 
13- Self Documenting code

Many times developers do follow naming convention (camel or pascal etc.) but the given names to variables, methods, functions and class etc. are not meaningful at all. Hence, at times developers write long code comments to describe what is the  purpose of each function or variable for instance. In my view, giving “self-describing” names will add a lot of value and also save developer’s time in documenting the code; as many software teams have a practice of writing comment above each line of code to explain the objective of code below. For instance, instead of “int age;” you may want to declare “int studentAge;”. Similarly, instead of just writing a function with name “GetData()” it will be preferred and more helpful to say “GetStudentsReportData()”. Similar techniques can also be applied to class names, functions and Unit Tests etc. But in case of unit tests, name(s) might get really lengthy, but this is totally fine and acceptable. Hence, a unit test method name “TestSuccessWithOneStudentRecordAddedToDb” will be much preferred than just saying “TestOneRecordData”.

Summary

Above mentioned code review guidelines are light weight, easy to look for and easy to apply techniques with larger impact on any code base.  Mostly it has been evident that simple things are either ignored or not cared about. These best practices can be added up with more guidelines or in combination with other techniques as applicable. Happy Coding…