Instance Members

Almost every class member (field, property, method) you've created so far has been an instance member. This is the default behavior in C# if you don't use the static keyword.

An instance member "belongs" to a specific instance (an object) of a class. This means that every time you create a new object from a class type, that object gets its very own copy of all its instance fields and properties. The methods of one instance operate on the data of that same instance.

Think back to our UserAccount class:

UserAccount userA = new UserAccount("Alice");
UserAccount userB = new UserAccount("Bob");
 
// Changing the Username property on userA...
userA.Username = "AliceTheAdmin";
 
// ...has absolutely no effect on userB's Username property.
Console.WriteLine(userA.Username); // Output: AliceTheAdmin
Console.WriteLine(userB.Username); // Output: Bob    

userA and userB each have their own separate Username property in memory. This is because Username is an instance property. You need an object to have an instance member.

Static Members

Now for the other side of the coin. A static member is a property, field, or method that does not belong to any individual object instance. Instead, it belongs to the class itself.

This means there is only one single copy of a static member, no matter how many objects of that class you create. All instances of the class share that same single static member. In fact, you can use static members even if you have created zero instances of the class!

Let's use an analogy. If a Car class has an instance property called Color, each car object has its own color (e.g., redCar.Color, blueCar.Color). But a static property like TotalCarsManufactured would be a single counter kept at the "Car Factory" (the class itself), shared by all cars ever made.

Let's turn that exact analogy into code. Here's a Car class that tracks how many have been made:

public class Car
{
    // A static property to count how many Car objects have been created.
    // There is only ONE copy of this variable for the entire class.
    // The 'private set' means it can only be changed from inside this class.
    public static int NumberOfCarsProduced { get; private set; }
 
    // An instance property. Each car object will have its own model name.
    public string Model { get; set; }
 
    // The constructor runs every time a new Car object is created.
    public Car(string model)
    {
        this.Model = model;
        NumberOfCarsProduced++; // Increment the single, shared static counter
    }
}   

In this example, every time we create a new Car object (e.g., new Car("Sport Car")), the constructor runs and increments the same, single, shared NumberOfCarsProduced counter. The Model property, however, is unique to each individual car object. This perfectly illustrates the difference between a class-level (static) member and an instance-level member.

How to Access Static vs Instance Members

The way you access these two types of members is fundamentally different, and this is a crucial concept to master.

Accessing Instance Members

To use an instance member, you must have an instance of the class (an object). You must first create an object using the new keyword, and then you access the member through the object variable using dot notation.

Syntax: objectVariable.InstanceMember

Accessing Static Members

To use a static member, you do not need an object instance. You access the member directly through the class name itself, also using dot notation.

Syntax: ClassName.StaticMember

Let's see our new Car class in action:

// Assume the 'Car' class from the previous example
 
// Access the static property even before any objects are created.
Console.WriteLine($"Initial cars produced: {Car.NumberOfCarsProduced}");
 
// Create the first Car instance
Car car1 = new Car("Cool Model");
// Access the instance property via the object variable
Console.WriteLine($"Car 1's model is: {car1.Model}");
// Access the static property via the class name
Console.WriteLine($"Cars produced so far: {Car.NumberOfCarsProduced}");
 
// Create a second Car instance
Car car2 = new Car("Extra Cool Model");
// Access this instance's specific property
Console.WriteLine($"Car 2's model is: {car2.Model}");
// Access the SAME shared static property again
Console.WriteLine($"Cars produced so far: {Car.NumberOfCarsProduced}");    

Expected Output:

Initial cars produced: 0
Car 1's model is: Cool Model
Cars produced so far: 1
Car 2's model is: Extra Cool Model
Cars produced so far: 2    

Notice we always use Car.NumberOfCarsProduced to get the total count and would never write car1.NumberOfCarsProduced (in fact, C# will give you an error if you try). You access static members through the class name (the "factory"), not through a specific instance (the "car").

Common Use Cases for Static Members

So, when would you actually choose to make something static?

Static Fields and Properties

These are great for data that should be shared across all objects of a class. A counter, like our NumberOfCarsProduced example, is a classic use case. You might also use a static field to hold a constant value that's related to the class, or a piece of shared configuration.

Static Methods (Utility Methods)

This is a very common and powerful use case. Static methods are perfect for creating helper or utility functions that don't depend on the state of any specific object. They just take inputs and produce outputs.

The entire System.Math class is a great example. You don't need a "math object" to find a square root; you just call Math.Sqrt(25). It's a collection of related utility methods. You could create your own:

public static class TestDataGenerator // A static utility class
{
    public static string GenerateRandomEmail()
    {
        // Logic to create a random string and append "@test.com"
        // It doesn't need any instance data to do its job.
        string randomPart = Guid.NewGuid().ToString().Substring(0, 8);
        return $"{randomPart}@test.com";
    }
}
 
// How to use it from anywhere:
// string randomEmail = TestDataGenerator.GenerateRandomEmail();    

Static Classes

If a class only contains static members (and has no instance members or constructors), you can – and should – mark the class itself as static, like we did with TestDataGenerator above. This prevents anyone from accidentally trying to create an instance of it with new and makes its purpose as a utility class clear.

Extension Methods

One of the most powerful and clever uses of static methods is a C# feature called extension methods. They allow you to "add" new methods to existing types without creating a new derived type or otherwise modifying the original type's code.

Imagine you wish the built-in string type had a method called WordCount(). You can't change the original string class, but you can write a special static method that acts like it's part of the string class:

// In a static class...
public static class MyStringExtensions
{
    // The 'this' modifier on the first parameter makes this an extension method
    public static int WordCount(this string str)
    {
        if (string.IsNullOrWhiteSpace(str)) return 0;
        return str.Split(new char[] { ' ', '.', '?' },
            StringSplitOptions.RemoveEmptyEntries).Length;
    }
}
 
// Now you can call it as if it were an instance method on any string!
string mySentence = "This is a sample sentence.";
int wordCount = mySentence.WordCount(); // Looks like a built-in method!
Console.WriteLine(wordCount); // Output: 5    

The key takeaway is that this powerful feature is built on top of the static members we're learning about now. We will cover extension methods in detail when we get to our lesson on LINQ, as LINQ's functionality is almost entirely composed of them.

Static Members in Test Automation

In test automation frameworks, static members are incredibly useful for creating shared utilities and managing global state (though global state should be used with care!).

A very common pattern is to create static helper classes. These classes group together related utility functions that your tests might need.

Example: A Static Configuration Reader

Imagine you have a configuration file that stores the base URL for your web application, browser type, and other settings. You don't want to read and parse this file in every single test. Instead, you can create a static class to handle it once.

public static class ConfigReader
{
    // This could read from a JSON file in a real static constructor (an advanced topic)
    private static readonly string _baseUrl = "https://mytestapp.com";
 
    public static string GetBaseUrl()
    {
        return _baseUrl;
    }
}
 
// From any test method, you can now easily get the URL:
// string url = ConfigReader.GetBaseUrl();    

Example: A Test Data Factory

Another great use case is a factory for creating random test data. You don't need a new "factory object" every time you want a random email.

public static class TestDataFactory
{
    public static string GenerateRandomUsername()
    {
        return "user_" + Guid.NewGuid().ToString().Substring(0, 6);
    }
}
 
// In a test:
// string randomUser = TestDataFactory.GenerateRandomUsername();
// loginPage.EnterUsername(randomUser);    

Using static classes and methods for these kinds of cross-cutting concerns makes your test code cleaner and avoids the need to constantly create and pass around utility objects.