Unit Tests, Integration Tests, and End-to-End Tests: What’s the Difference?

• Unit tests focus on testing individual units or components of your application in isolation. This type of test verifies whether the unit/component works correctly and adheres to its business logic.
• Integration tests aim to test multiple units or components together, ensuring that they interact properly. Integration tests can uncover issues related to data flow, communication between components, and external dependencies like databases.
• End-to-end (E2E) tests simulate a complete user scenario by testing the entire application from start to finish. E2E tests can help identify issues related to multiple components, external APIs, and user interfaces.

public class InMemoryDbAppFactory : WebApplicationFactory<Program>
{
    private readonly string _environment;

    public InMemoryDbAppFactory()
    {
        _environment = "IntegrationTests";
    }

    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        Environment.SetEnvironmentVariable("ASPNETCORE_ENVIRONMENT", _environment);
        builder.UseEnvironment(_environment);
        builder.UseSetting("https_port", "8080");

        builder.ConfigureTestServices(services =>
        {
            services.RemoveAll<ITestRepository>();
            services.TryAddTransient<ITestRepository, TestRepositoryTest>();

            // Anonymous authentication
            services
                .AddAuthentication("Test")
                .AddScheme<AuthenticationSchemeOptions, TestAuthenticationHandler>("Test", options => { });
        });
    }
}

public static partial class ServiceCollectionExtensions
{
    public static IServiceCollection AddDbContexts(
        this IServiceCollection services,
        IConfiguration configuration,
        IWebHostEnvironment environment
    )
    {
        if (environment.IsEnvironment("IntegrationTests"))
        {
            var connDb = new SqliteConnection("DataSource=db;mode=memory;cache=shared");
            connDb.Open();
            services.AddDbContext<dbContext>(options => options.UseSqlite(connDb));
        }
        else
        {
            services.AddDbContext<dbContext>(
                options => options.UseSqlServer(configuration.GetConnectionString("ConnectionString")).UseExceptionProcessor(),
                ServiceLifetime.Scoped
            );
        }

        return services;
    }
}

[Collection("MemoryDbIntegrationTests")]
public class ApiTests : IClassFixture<InMemoryDbAppFactory>
{
    private readonly InMemoryDbAppFactory _factory;
    private readonly HttpClient _client;

    public ApiTests(InMemoryDbAppFactory factory)
    {
        _factory = factory;
        _client = factory.CreateClient();

        // Ensures a clean database before each test
        factory.ResetDb();
    }

    [Fact]
    public async Task GetList_Should_Return_List()
    {
        // Arrange

        // Act
        var response = await _client.GetAsync("/api/list");
        var content = await response.Content.ReadFromJsonAsync<IEnumerable<Dto>>();

        // Assert
        response.EnsureSuccessStatusCode(); // Status Code 200-299
        content.Should().NotBeNull();
        content.Should().HaveCount(2);
    }
}

Using an in-memory database for integration tests has both advantages and disadvantages:

Advantages:

• Faster test execution: In-memory databases provide quicker test execution times since the data is stored in memory instead of on disk. This can significantly improve your overall testing performance and help you find issues faster.
• Easy to set up and tear down: In-memory databases are easy to create, modify, and delete without the need for external dependencies or configuration changes. This makes it easier to write, run, and maintain your tests.
• Consistent test data: In-memory databases allow you to create a known set of data for your tests, ensuring that each test starts with the same initial conditions. This can help reduce the likelihood of inconsistent test results and make it easier to identify issues related to data flow or dependencies between tests.

Disadvantages:

• Limited scalability: In-memory databases have limited capacity and may not be suitable for testing large datasets or complex scenarios that require high levels of concurrency.
• Lack of realism: In-memory databases may not accurately represent the behavior or performance of a production database, especially when dealing with complex queries or data modification operations. This can make it difficult to identify issues related to database schema, indexing, and query optimization.
• Limited support for advanced features: using SQLite as our in memory database we don’t have support for multiple schemas and some advanced query features.
• Seed data: the need to create seed data can be tedious and time consuming.

When deciding whether to use an in-memory database, mock data, or a real web server in memory for your integration tests, consider the specific requirements of your project and weigh the advantages and disadvantages of each approach. In many cases, using a combination of testing types and approaches can help you ensure the stability, reliability, and performance of your .NET WebAPI application.

The post Integration Tests in .NET WebApi appeared first on Blog IT.

How to install JMeter, what are the components of it and how to use it. It will, also, show a short introduction of what is performance testing.

First of all, let’s talk about Performance Testing. What is Performance Testing?

Performance Testing is a software testing process used for testing the speed, response time, stability, reliability, scalability and resource usage of a software application under a particular workload.  
The focus of Performance Testing is checking a software program’s

• Speed – Determines whether the application responds quickly
• Scalability – Determines the maximum user load the software application can handle.
• Stability – Determines if the application is stable under varying loads

What is the Purpose of doing it?

The main purpose of performance testing is to identify and eliminate the performance bottlenecks in the software application.

Now let’s introduce JMeter

How to install it?

JMeter is an application base in java. This means, that every computer with java installed can run this application. So let’s see how to install it.

1- Download Java.

 First of all, you will need to install Java on your computer. Here you can download and Install the latest version of Java SE Development Kit https://www.oracle.com/java/technologies/javase-downloads.html.

2- Download JMeter.

At the point of writing, the latest version is Apache JMeter 5.4.1 (Requires Java 8+) and you can download it here http://jmeter.apache.org/download_jmeter.cgi. Choose the Binaries file (either apache-jmeter-5.4.1.zip or apache-jmeter-5.4.1.tgz).

3- Installation.

Installing Jmeter is easy! You only need to unzip the file to a directory of your choice and that’s it!

4- Start JMeter

JMeter can be used in 3 modes. These 3 modes are:

1. GUI Mode
2. Server Mode
3. Command Line Mode

In this article, we will focus on GUI Mode. So, to start the GUI Mode, you will need to execute the following file /bin/ApacheJMeter.jar. This will open the application as the following example.

How to use JMeter?

Now that we have JMeter installed and running, we need to understand the components that are used to create a Test Plan.

When we open JMeter, we can see that there is already a “Test Plan” component. This component is where we add components for our JMeter Test. Here is an image of how these components are organized.

The components that we are gonna talk here will be:

• Thread Group
• Samplers
• Listeners
• Config Elements

Thread Group

Thread group is a collection of threads. This is the component where you define how many threads will run. Essentially, each thread represents a user using the application under test.

The thread group let’s you set the value of threads that you want to run(simulating the number of users, that you to test, using your app).For example, if you set threads number to 100. JMeter will create and make 100 request to the application under test.

Samplers

JMeter supports testing HTTP, FTP, JDBC and many other protocols.

We already know that Thread Groups simulate user request to the server, but how does a Thread Group know which type of requests (HTTP, FTP etc.) it needs to make? The answer is Samplers.

The user request could be FTP Request, HTTP Request, JDBC Request, etc. In this example, we will concentrate in HTTP Request.

Listeners

Listeners shows the results of the test execution. They can show results in a different format such as a tree, table, graph or log file.

Graph result listeners display the server response times on a Graph.

View Result Tree show results of the user request in basic HTML format.

Table Result show summary of a test result in table format.

Log show summary of a test result in the text file.

Config Elements

Set up defaults and variables for later use by samplers.

The figure below shows some commonly used configuration elements in JMeter.

Let’s create a test

As was shown before, JMeter starts with a Test Plan Component already created (you can change the name to anything more suitable to your case). 

Now let’s start creating our test. In this case we will use https://my-json-server.typicode.com/ to simulate an API.

Initially, let’s add a Thread Group. Right click on the test plan, then Add -> Threads(Users) -> Thread Group.

You can see that there is some settings that we need to adjust. At the top, there is a setting that says Action to be taken after a Sampler Error. Normally, I always use this in Continue but you can use the one that suits your case.

The next 3 settings will be the ones that we gonna focus for now.

• Number of Threads (users) – is the number of threads(users) that will be running your test plan.
• Ramp-up period (seconds) – is the value in seconds that defines how much time until all threads are working. Example: 100 Threads and 10 seconds of ramp-up period, this means that the threads will start, gradually, until at the point of 10 seconds all 100 threads will be working.
• Loop Count – You can set this to the Infinite and will only stop threads when you press the button to stop. Also, you can set a loop count, that is the times that each thread will execute the test plan. Example, if you put the value 3, the threads will execute the plan 3 times and then will stop.

So, in our example lets try 10 threads, with 5 seconds of Ramp-up Time and the value 3 in the loop count. I will also change the name of the thread group to know how many threads I am using. It Should look like this.

Let’s continue adding more components. This time, let’s add a way to define variables. Right-click on the Thread Group, then Add -> Config-Element -> User Defined Variables. 

This component will let you define some variable to use afterwards. Let’s define some.

• url: my-json-server.typicode.com
• postId: 1

 Now, to use these variables in other components you will need to do it in the following way.

• ${url} for the url Value 
• ${postId} for the postId Value

Finally, let’s add some real requests. Here as example we will make 3 different requests. Http Request to get all posts, Http Request to get one Post, and Http Request to Post a new Post. Remember that the site used in this example has paths to request posts and to add posts.

How to add an HTTP Request ? Right-click on the Thread Group, then Add -> Smapler -> Http Request.

Now that we have an Http Request component, let’s configure to make a Http Request to get all posts. The path to this request is https://jsonplaceholder.typicode.com/posts. The configurations of this component are:

• Protocol -> “https”
• Server Name or IP -> ${url} (because we have this value defined in a variable)
• Port Number -> in this case, nothing but if you need to your specific case, here is where you put the port number. Example: to make a request to https://localhost:80, you would need to put the value 80 in here.
• HTTP Request -> GET
• Path -> “/typicode/demo/posts”

Now that we have everything, let’s run ? Click on the start Button above and see what happens. Nothing ? Stop the process and let’s see what is missing.

The piece that is missing is listeners. We need listeners to understand what is happening. In this case, the View Results Tree and Summary Report. Let’s add these two listeners by Right-clicking in the Thread Group, then Add -> Listener -> View Results Tree and Add -> Listener -> Summary Report.

Now, if you start the process, you will see that these listeners represent information about the request. 

The View Results Tree show every request information. In here, you can see the request body and headers, and the response body and headers.

In this example, when we choose the Response Body of one request we will see that there will be a JSON with data relative to what they call as posts.

The Summary Report Aggregates the information of different types of request. In this case, we only have one request, so, it will show informations about that request.What are the informations that this will show ? 

• #Samples – are the number of requests made 
• Average – shows  the average time needed to make these requests 
• Min – shows the value of the request that take less time to finish
• Max – shows the value of the request that take more time to finish
• Std. Dev. – shows the standard deviation of the request times to the average
• Error % – shows the percentage of requests that failed
• Throughput – shows the number of requests processed by time 
• Received KB/sec –  shows the amount of data downloaded from the server  time
• Sent KB/sec – shows the amount of data uploaded to the server time 
• Avg. Bytes – shows the average size of the response sample

We have all we need, let’s add more Requests. Let’s create a request that creates a post, and create a request that obtains only one post. Also, change the name of the Http Request components to now what is the correspondent request. Remember to put the Http Request before the listeners. The Listeners will only listen to what are before them. Remember this! 

The create a post request configurations are:

1. Protocol -> “https”
2. Server Name or IP -> ${url} (because we have this value defined in a variable)
3. HTTP Request -> Post
4. Path -> “/typicode/demo/posts”
5. Body Data – we will put a JSON like this {“title”: “Car Crash”}

And, The get one post request configurations are:

1. Protocol -> “https”
2. Server Name or IP -> ${url} (because we have this value defined in a variable)
3. HTTP Request -> Get
4. Path -> “/typicode/demo/posts/${postId}”

Run the test plan and see the results. Try to do it for another API. 

These are the basic examples that we have for you right now. More advanced tips will come. 

See you next time.

References

• https://www.guru99.com/jmeter-element-reference.html
• https://www.guru99.com/hands-on-with-jmeter-gui.html

The post Performance Testing An API, How To Start Doing It With JMeter? appeared first on Blog IT.

The script below is the result of a collection of snippets and bits of code I found in various places around the Internet that allowed me to solve this problem.

For this example, I only want to send the files which have a specific extension (.html) and that exist in a specific folder (passed as parameter to the PowerShell script). Of course, you are free to remove this extension filtering for your own purposes.

Also, note that Outlook must have a configured email account for the sending process to succeed.

# Check to see we have all the arguments
if($args.Count -lt 1)
{
Write-Host "Use: SendMail.ps1 <Path>"
Write-Host
Write-Host " <Path>: Full path for the folder which contains the files"
Write-Host
exit
}

$FullPath=$args[0]

#Get an Outlook application object

$o = New-Object -com Outlook.Application

$mail = $o.CreateItem(0)

#2 = High importance message
$mail.importance = 2

$mail.subject = "This is the subject of the mail"
$mail.body = "This is the body of the email. It has been automatically generated by a script."

#separate multiple recipients with a ";"
$mail.To = <INSERT THE RECIPIENT HERE>
#$mail.CC = <OTHER RECIPIENT 1>;<OTHER RECIPIENT 2>

# Iterate over all files and only add the ones that have an .html extension
$files = Get-ChildItem $FullPath

for ($i=0; $i -lt $files.Count; $i++) {

$outfileName = $files[$i].FullName
$outfileNameExtension = $files[$i].Extension

# if the extension is the one we want, add to attachments
if($outfileNameExtension -eq ".html")
{
$mail.Attachments.Add($outfileName);
}
}

$mail.Send()

# give time to send the email
Start-Sleep 20

# quit Outlook
$o.Quit()

#end the script
exit

You can invoke the script presented above, by using a simple command window and giving the following command:

I hope this helps!

The post Sending an email with attachments using Outlook and PowerShell appeared first on Blog IT.

To do this, we’ve been using Telerik’s WebUI Test Studio. Although this tool is not exactly SharePoint-oriented, it still allows us to test our SharePoint components in a very satisfactory way.
This does not mean, however, that we are able to use all the recorded steps in an unmodified way. In fact, sometimes we have to tweak the recorded steps manually in order to select the proper UI element. For instance, sometimes the recording tool will assume that we are clicking on an html div element instead of the table cell that is contained in it. Thus, what we usually do is try to narrow down the search criteria of the automation framework by using specific attributes of that table cell or if all else fails, we convert that particular recorded step into manual C# code, which we can manipulate the way we see fit.

In this case, I was trying to simulate a text insertion into the SharePoint people picker control, but the recording tool was not capturing the events correctly.

After exhausting all automatic possibilities (by tweaking the automation framework’s search logic of element attributes) I decided to use manual C# code to solve the problem.

Step 1: I recorded an automatic step, by clicking anywhere on the page. This gave me a step that I could transform into code. Then I converted the recorded step into a coded step.

This creates an automatic C# code file which we can edit to suit our needs. The automatic generated code looks something like this:

[CodedStep(@"Click 'td_73'")]
public void Click_td_73_CodedStep()
{
    // Click 'td_73'
    HtmlTableCell td_73 = Pages.Home__AutoTests.td_73;
    td_73.Wait.ForExists(10000);
    td_73.Click(false);
}

Step 2: In this case, I wanted to simulate the insertion of text into the people picker. Thus, I used WebUI Test Studio’s Overlay Surface feature to correctly identify the element I was trying to manipulate.

By checking the page’s DOM tree, I was able to determine that the element I was trying to manipulate was an HTML textarea, with a div before it. However, when we try to insert text into the textarea element, nothing happens.

Step 3: After a few tests and after discussing the issue in the Telerik support forums, I was able to work around the problem.

In fact, the element that we want to manipulate isn’t the textarea itself, but the div above it. So, we start by adding the div element to the project Elements pane so we can reference it freely in the C# code.

Step 4: After that, we must insert the following code into the recorded step that was converted to manual C# code ( the idea is to replace the automatically generated C# code that was presented in Step 1).

[CodedStep(@"Insert into people picker")]
public void InsertItemInPeoplePicker_CodedStep()
{
    //Note: the div_PlaceHolder__UpLevelDiv object represents the div we want to 
    //manipulate. It was added to the Project Elements in Step 3.
    HtmlControl peoplePicker = Pages.Customize_Workflow.div_PlaceHolder__UpLevelDiv;
    peoplePicker.Wait.ForExists(10000);
    peoplePicker.ScrollToVisible(ArtOfTest.WebAii.Core.ScrollToVisibleType.ElementTopAtWindowTop);
    ActiveBrowser.Window.SetFocus();
    peoplePicker.MouseClick();
    Manager.Desktop.KeyBoard.TypeText("testDeveloper", 200);
}

After the replacement of the automatic code with the code presented above, it is possible to insert the text “testDeveloper” into the people picker. And that’s it.

Hope this helps.

The post Automatic Testing with People Picker in SharePoint 2007 appeared first on Blog IT.