The answer to all these questions is mutation testing. Interested? Read on

Code Coverage – Our Old Friend

You probably know what code coverage is. Traditionally, many teams tend to measure how good their tests’ suite is by percentage line / statements / functions coverage. Some even require this metric to be 100%. Let’s start with this well-known approach first.

We are working with TicketsPriceCalculator class today. It contains some simple business logic:

As you can see, the class has one function whith returns the total price to be paid for a set of tickets. On the way, it applies various discounts based on some business rules. Fair enough.

It’s a critical piece of business logic for the app we’re working on, but it has never had any tests. We were asked to write unit tests for this class. Our manager strictly requires the code coverage to be 100%. Let’s do it then. We will go line by line, analyze the business logic and add the tests. Below, you can see the results of running those tests (you can find the tests code here):

Wow, that’s awesome! We did a great job. We have 8 unit tests which provide 100% statements, branch, functions and lines coverage!

So now we are really safe, aren’t we?

Yeah… until you know what mutation testing is

What Is Mutation Testing?

The idea of mutation testing is to mutate (change) our code. Mutation testing tools introduce changes into our production code. These changes can be really anything – from reverting a condition of an if statement, to changing some operators or changing a string value. For instance, here are some logical mutations Stryker Mutator is able to introduce (you can find the list of all mutations supported by Stryker here):

In effect, they generate modified versions of our code, which are called mutants. Makes sense

Each mutant contains a single modification in our source code. What happens next is crucial. Mutation testing tool takes this mutant (it is used as the code under tests now) and executes all of our unit tests against it. The result may be twofold:

• all tests have passed. In other words, the mutant has survived. This is a bad situation. It implies that the modification of our source code was not detected by our tests
• at least one test has failed. In other words, the mutant has been killed. This is a good scenario. It means that our tests detect changes in the production code and efficiently cover this particular scenario.

The flow is more or less like this schema from Peter Evans’ blog presents:

But why would anyone change the production code on purpose by introducing some stupid changes? It may seem counterintuitive for now, but let’s see how we can use it to our leverage.

Mutation Testing with Stryker Mutator

Let’s clearly state what we are starting with:

8 unit tests, 100% code coverage

Let’s now run mutation testing on our code. We are using TypeScript here, so let’s go with Stryker Mutator.

Here’s the result of running Stryker with npx stryker run on our code:

As you can see, 53 mutants were killed, but 15 of them survived. This gives us a mutation score of 78%. Let’s call it mutation coverage from now on. So to make it clear, this is our starting situation:

8 unit tests, 100% code coverage, 78% mutation coverage

Let’s now see how to kill those remaining mutants.

Killing First Mutants

In order to kill the mutants and improve our mutation score, we need to write more unit tests. Sounds logical, doesn’t it?

If still not, let’s take a deeper look at mutation tests results in VS Code. Stryker lists details of every survived mutant, for example this one:

Stryker changed the greater or equal (>=) operator to greater operator (>). This is a very common and very useful mutation. It usually means that our tests don’t cover the edge case associated with this particular condition.

In this case, the edge case value seems to be 5. More precisely, what happens if the number of business class tickets is exactly 5? We don’t know, because there is no test for this particular edge case!

Let’s add it:

The test passes. Let’s run mutation tests again:

That’s it! We have a new unit test and 1 more mutant killed Current state:

9 (+1) unit tests, 100% code coverage, 79% mutation coverage

I think you’re now getting what this is all about. We should be adding unit tests to cover the edge cases detected by mutations until all (or most) mutants are killed.

Mutation Testing – Free Unit Tests Generator

After adding 1 more test, the results look as follows:

10 (+2) unit tests, 100% code coverage, 86% mutation coverage

Finally, this is what we managed to get after a few minutes of work:

And we now have 17 unit tests in our suite! The final score looks like that:

17 (+9) unit tests, 100% code coverage, 96% mutation coverage

Notice what happened here. We started with 8 unit tests and finished with 17! This is awesome! That’s how mutation testing is a free unit tests generator. And you don’t even need AI for that

What’s more, the generated mutations even forced me to make a little tweak to the production code. It exposed some things that didn’t make sense. I could make this change to the production code, because my tests’ suite was already quite substantial.

Note that I didn’t push to gain 100% mutation coverage. The 3 mutants that survived don’t make much sense in our case. I encourage you to get the code and execute npx stryker run in the application folder to see for yourself

The percentage value doesn’t matter in that case. What matters is that we got 9 new unit tests and our tests’ suite is more robust. Now we can go and tell our manager that the business-critical code is well tested

So What Now?

I hope you see how valuable mutation testing is. It’s not a perfect tool that suits all cases. For example, it’s not easy to use mutation testing for complex legacy code. However, if your logic is nicely isolated, it could be a great tool. Especially if your production code heavily depends on calculations and many conditions. You may be surprised how many edge cases mutation testing can find.

I also love using mutation testing with TDD. These two techniques nicely complement each other.

I encourage you to go and try mutation testing. There are different mutation tools for various programming languages:

• C#, JavaScript, TypeScript, Scala: Stryker Mutator
• Ruby: mutant
• Java: pitest
• PHP: Infection
• C++: Mutate++

…and probably many more. Just do some research for the language you work with and give it a try Because testing is cool, isn’t it?

You can find the full source code used in this article here.

The post What is Mutation Testing and Why Should You Use It? appeared first on CodeJourney.net.

If you ever had an API action defined like that in your controller:

and fetched this data using TypeScript in the following way:

at some point, you probably also experienced the desynchronization of backend (C#, in our example) and frontend (TypeScript) types definitions. What if someone has changed the C# version of UserViewModel, but no one corrected its TypeScript’s equivalent?

Your TypeScript fetching code will tell nothing about that. There will be no error, even though the fetched data doesn’t match the expected UserViewModel type.

I’ll try to address this issue in this article Let’s see how typing API responses with zod can help us here.

Synchronization of Backend and Frontend API Typings

First, why would we want to keep the backend and frontend models in sync?

For me, that’s the purpose of using TypeScript. We want our code to be as well-typed as possible. For instance, we normally want the data displayed to the user to be fully typed. TypeScript enhances our programming experience by providing us with typing information. Thanks to that, we know what is what and what contains what. We also express what types of data we expect in particular cases.

The APIs mostly return JSON data, which can be anything. Because of that, it is much easier to have the data returned from the API fully typed in TypeScript. Thanks to that, we know what properties are available on the data models received from the API and whether we can use and display them to the users.

The sample code used within this article is available on GitHub. We will use ASP.NET Core (C#) and React (TypeScript) apps as examples.

Models synchronization example

As we saw in the beginning, a classic example is an API controller that returns a strongly-typed data:

The returned data type is a collection of UserViewModel objects. Here’s the C# definition of this type:

Its equivalent is also defined on TypeScript side:

Usage in TypeScript

Cool. With this simple code, we can create a usersService.ts file and fetch our users’ data from the API. Notice how we make this call strongly typed:

Everything looks legit. We can use the data retrieved from the API in UsersList component and everything is nicely typed:

The data is even perfectly displayed:

So, what can go wrong here?

The Problem – Typings’ Desynchronization

Let’s say that a backend developer implements a requirement to rename “loyalty points” into “fidelity points”. Easy. (S)he renames LoyaltyPoints property in the C#’s UserViewModel to FidelityPoints.

The new C# model looks as follows:

Nice! The backend dev is a very good programmer, so (s)he even launches the React web application to make sure that everything still works correctly and there are no errors in the dev console:

After a quick look, everything looks awesome. The users list is displayed, there are no errors in the console. Apparently, these test users don’t have any loyalty points assigned – that’s why the empty values in “Loyalty points” column. What’s more, translators will update the column’s translation later. We are good! Let’s go on prod!

I guess you already know what went wrong here. API definition changed, but TypeScript didn’t inform us about that Our UserViewModel still uses the old property name:

However, it still works. When rendering the UsersList, we simply get undefined in place of loyaltyPoints:

In the end, this is all JavaScript there. What’s interesting, the renamed fidelityPoints property is already there at runtime:

but no one cared about it

With the current solution, we will never be informed soon enough about API models changes in our React application. In the best case, we’ll get an undefiend or null error when clicking through the app. However, it’s usually an end user who finds such problems on production. This is definitely not what we want

We can solve this problem by typing API responses with zod. Let’s now see how to do that.

The Solution – zod

Our remedy – zod – is quite a decent npm package with with ~600k weekly downloads. Its GitHub page advertises the library as TypeScript-first schema validation with static type inference.

You can definitely do many things with zod. It can be used together with libraries like react-hook-form to perform complex forms validation. However, in our case, we’ll treat zod as a solution for better typings in TypeScript.

Adding zod to React app

First, let’s install zod into our React application:

npm i zod

First schema definition with zod

With zod, we define our types in a slightly different way. Instead of creating a type or interface directly, we first create a schema. In our case, we can define a UserViewModelSchema using z.object creator function:

Few interesting parts here:

• Line 2: notice how zod helps us to define types like Guid with built-in schemas like uuid()
• Line 8: first, I used AddressViewModelSchema here. This is a custom schema of an AddressViewModel object, which is another type used internally in UserViewModel. You can use such custom schemas in other schemas. Also notice the nullable() call here, which makes the address property nullable

First step done – we have our UserViewModelSchema. But can we use it instead of UserViewModel type? Not really. Schema is used for validation purposes only. We still need the UserViewModel TypeScript’s type.

Inferring type from zod’s schema

Fortunately, zod comes with a handy z.infer function that allows us to infer the type from the schema.

Finally, the userViewModel.ts file looks as follows:

We can use the exported UserViewModel type as previously used type. It’s an equivalent, inferred from UserViewModelSchema.

Validating API responses with zod schema

One last step is to make use of UserViewModelSchema. Let’s modify the getAllUsers function from usersService to validate the data received from the API against our schema:

Notice the usage of z.array. This function call tells zod to validate an array of objects meeting the rules defined by UserViewModelSchema, not a single object.

Now, let’s run our React app and see what happens when we click the “Fetch users” button:

This is awesome! Exactly what we wanted – a schema validation error for API response. Notice how the error message precisely points to the missing (or wrong, in other cases) property. It tells us we expected a number called loyaltyPoints, but instead we received undefined. The reason for this error message is that the loyaltyPoints field is Required in our schema.

After renaming loyaltyPoints to fidelityPoints in UserViewModelSchema and updating the UsersList component accordingly, everything works fine again.

We are now fully typed and prepared for the future, in case an issue with desynchronization of frontend and backend typings happens again

Summary

Today, we’ve seen how typing API responses with zod can help us detect frontend and backend models desynchronization. Schema validation throws errors when the data doesn’t match its expected shape.

Remember that zod is an extended library with many options. I recommend exploring them on your own. An interesting feature we didn’t cover in this article is strict mode, which doesn’t allow additional fields not present in the schema definition when validating the data object.

The open question remains whether to use schema validation on production. One could think that it’s better to not throw any validation errors, because JavaScript may just work. However, I think that throwing an error is always better than silently letting things through. An error lets programmers, automated tests or manual testers to detect the issue before the end user does

You can explore the complete code presented in this article here.

The post Typing API Responses With Zod appeared first on CodeJourney.net.

The title picture of this article shows the end result. If you want to know the solution, keep reading

Context

The context of this need is very simple. I have a unit test in which I want to perform some operations and keep the test running indefinitely afterwards. The use case might be instantiation of an in-memory test server. After that, I want to inform the user (programmer or the one running the test) that the server is up and running. I want to do that before the test finishes. In other words: I want to write the test’s output while it’s still running.

In my case, I was running two .NET Core apps in-memory. The backend server app and the ASP.NET Core web application. In the process, the web app got its IP address assigned dynamically. Meaning that the IP was different with each test run. This particular test was used to run the app in-memory and let the user manually use the application. It means the user must know the IP/URL of the in-memory web app. That’s why I needed to output the dynamic IP address into the NUnit test output

Solution

The solution to write test progress to the console with NUnit is very simple. To do that, use TestContext.Progress.WriteLine(string) method from NUnit.Framework namespace:

And that’s it! I’m publishing this simple solution, because it took me some time to find

I previously tried with TestContext.Out.WriteLine, System.Diagnostics.Trace.WriteLine and System.Console.WriteLine, but all of them output the text after the test finishes.

Finally, you can also run the test from cmd using dotnet test:

Hope it’s useful!

The post Write Test Progress To The Console With NUnit appeared first on CodeJourney.net.

NHibernate.Exceptions.GenericADOException: could not load an entity: 
...
 ---> Microsoft.Data.SqlClient.SqlException (0x80131904): Database 'myappdb' on server 'myapp.database.windows.net' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '{EB501CF2-2F21-4E28-9042-2B83EEE57B91}'.

The database is not currently available was very interesting to me. I struggled a bit with solving that, so if you want to know how I did it – continue reading

The problem

My .NET 6 app is an Azure App Service, and it uses SQL Server database. Quite standard Azure stuff.

The issue was that when opening the ASP.NET web app after some time of inactivity, there was an HTTP 500 error. When I checked the logs, the full error looked as follows:

NHibernate.Exceptions.GenericADOException: could not load an entity: [MyApp.Infrastructure.DomainObjects.ApplicationUser#37931c5a376748d7a49f215ca30283a2][SQL: SELECT applicatio0_.applicationuser_key as id1_3_0_, applicatio0_1_.UserName as username2_3_0_, applicatio0_1_.NormalizedUserName as normalizedusername3_3_0_, applicatio0_1_.Email as email4_3_0_, applicatio0_1_.NormalizedEmail as normalizedemail5_3_0_, applicatio0_1_.EmailConfirmed as emailconfirmed6_3_0_, applicatio0_1_.PhoneNumber as phonenumber7_3_0_, applicatio0_1_.PhoneNumberConfirmed as phonenumberconfirmed8_3_0_, applicatio0_1_.LockoutEnabled as lockoutenabled9_3_0_, applicatio0_1_.LockoutEnd as lockoutend10_3_0_, applicatio0_1_.AccessFailedCount as accessfailedcount11_3_0_, applicatio0_1_.ConcurrencyStamp as concurrencystamp12_3_0_, applicatio0_1_.PasswordHash as passwordhash13_3_0_, applicatio0_1_.TwoFactorEnabled as twofactorenabled14_3_0_, applicatio0_1_.SecurityStamp as securitystamp15_3_0_ FROM ApplicationUsers applicatio0_ inner join dbo.AspNetUsers applicatio0_1_ on applicatio0_.applicationuser_key=applicatio0_1_.Id WHERE applicatio0_.applicationuser_key=?]
 ---> Microsoft.Data.SqlClient.SqlException (0x80131904): Database 'myappdb' on server 'myapp.database.windows.net' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '{EB501CF2-2F21-4E28-2342-2B836E35E891}'.
   at Microsoft.Data.ProviderBase.DbConnectionPool.CheckPoolBlockingPeriod(Exception e)

There were two characteristics of this error:

• it always appeared after some time of not using the web app
• I never reproduced it locally

So it must have been something wrong with Azure.

Transient issues in Azure databases

First thing I did, obviously, was checking Azure App Service logs. This is what I found:

The first recommended step got me curious. To reduce the impact of connection issues caused by future reconfiguration, please implement retry logic in your code.

So I started reading. There’s even official Microsoft documentation for that. It basically says that in the cloud environment you’ll find that failed and dropped database connections happen periodically.

I must admit it seemed quite new to me. However, I started digging into that. I used Polly to implement the retry logic in my app. I found few places where there was an NHibernate query for fetching users executed and wrapped it into the retry policy.

Nothing worked. I was still getting the error. Then, after some talks with my coworkers, we found the real reason behind that…

Solution: Azure database tier

When talking about the issue with my teammates, someone mentioned that the databases in Azure are serverless by default.

I logged into the Azure Portal and checked the “Compute + storage” settings my SQL database my app used:

Indeed, the tier selected was “General purpose (Scalable compute and storage options)” with “Serverless” compute tier selected.

I changed it to “Basic (For less demanding workloads)”:

and… it worked All errors saying that the database is not currently available disappeared. I also removed all Polly-related code for retry policies.

A little explanation

Why do serverless databases in Azure behave like that?

I finally found this explanation in the Microsoft documentation:

If a serverless database is paused, then the first login will resume the database and return an error stating that the database is unavailable with error code 40613. Once the database is resumed, the login must be retried to establish connectivity

That blew my mind! It means that the database is not currently available exception is expected. There’s also another part there:

Database clients with connection retry logic should not need to be modified. For connection retry logic options that are built-in to the SqlClient driver, see configurable retry logic in SqlClient.

Apparently, users of ORMs like Entity Framework should not have to worry about those issues. Unfortunately, NHibernate doesn’t have such built-in transient errors retry logic. That’s why I experienced this particular issue and couldn’t find any straightforward solution online. Simply not many people (if anyone at all? ) experienced this before.

If you want even more details and context, check out this article: SHOULD I USE SERVERLESS FOR ALL MY AZURE SQL DATABASES?

What if I want to use serverless Azure database?

Well… if you really want to use the serverless features of Azure, you might be struggling with NHibernate. As I mentioned, apparently there’s no built-in transient failures retry mechanism in the ORM. There’s one promising solution here. However, currently it’s build for NHibernate 3.3.1.4000, so it doesn’t work with the current version. There’s a Pull Request and an issue opened for upgrading it to the newest version and .NET 6/7. Let’s hope it is done soon.

Otherwise, you can try using Polly as I did initially. However, I didn’t manage to make fully working.

If you have any other idea or solution – let us know in the comments below.

Conclusion

I hope this article saves you some hours of debugging, so you can quickly solve this database is not currently available error in Azure. I wish I found this article on another website few weeks ago

The post How To Fix SqlException Database Is Not Currently Available On Azure (0x80131904) appeared first on CodeJourney.net.

Today I can say that it was the best decision we could make. TypeScript makes working with JavaScript, which is sometimes surprising and quite hard to understand, so much better experience. However, there were some challenges on this journey. If you want to know what issues we met and how we solved them, but also what huge advantages TypeScript gave us – read on

I will not discuss TypeScript itself in this article. This is a pure recap of challenges and the experience I gained when migrating to TypeScript.

Choosing migration strategy

Before starting migrating to TypeScript, we had to choose the best strategy for this process. There were two possibilities we considered: migrating the whole JavaScript codebase to TypeScript at once or switching to TypeScript compiler and migrating part-by-part.

For those who are not familiar with TypeScript – it is a superset of JavaScript which adds typing information to your JS code. It means that every JavaScript code is also a valid TypeScript code. When compiling TypeScript code, TS compiler removes the typing data and outputs readable, vanilla JavaScript code ready to be executed.

Migrating the whole codebase to TypeScript would mean to change all files extensions to TypeScript ones: .js to .ts and .jsx to .tsx. It would also mean that TypeScript compiler starts checking types in those files. This approach is doable, but – depending on the size of your project – can take a long time. During migration the code would be frozen until you fully migrate the project. Also, for TypeScript beginners, it could be a bit frustrating having to type everything at once or use some tricks to tell TypeScript to ignore checking types in many cases (because the type is not known at this stage, or we want to do it later etc.).

Because of that, we decided to migrate part-by-part, having JavaScript and TypeScript files at the same time. It is possible thanks to enabling allowJs TS compiler option. It means that TypeScript will compile both TS and JS files. Such approach allows the coexistence of old JS code with the new TS parts. It also allows moving only chosen parts of the application to TypeScript at the beginning and come back to the others later.

In our web application the biggest JS files have few thousand lines of code. Some of this legacy code still didn’t use React, but Backbone as their framework. We didn’t want to touch these oldest files in the beginning. Instead, we moved few recently written functionalities to TypeScript straightaway and decided to implement everything new in TS as well.

Bright side of migrating to TypeScript

If you are a JavaScript developer, the best advice I can give you is to start using TypeScript In this section I’m describing what positively surprised me since the beginning of starting to use TypeScript.

Types “for free”

As soon as we changed our transpiler from babel-loader to ts-loader, I wanted to know how we can get typing information for already-installed npm packages. It turns out that for 98% of the packages we used there’s already a typing information available as a separate npm package.

In most cases if you have a npm package called abc there’s a typing package available called @types/abc. I explored our package.json and for each package listed there I just executed npm install @types/package-name. 2 or 3 older or not-so-popular packages didn’t have types definitions available, but for the rest we got types for free, without having to type anything ourselves. This was a first, very nice surprise

You can find more information about TypeScript types definition packages, as well as contribute one yourself, here.

All new code is typed

As I wrote before, every new feature we’ve added since the migration is written in TypeScript. Thanks to that, all new code we write is strongly typed. What’s remarkable here is that it required almost no effort. We just switched the compiler to TS (with a small struggle with webpack configuration, about which you can read below) and suddenly got into typed world for every new feature we implement. Quite impressive, isn’t it?

JS-TS friendship

Coexistence and friendship between JavaScript and TypeScript is HUGE. These two creatures are not enemies – they are best friends We’ve already gone through many scenarios when we needed to use something written in TS in a JS file and otherwise. It turns out that all of these scenarios are manageable. Sometimes you need to import something differently (for example using require instead of import), but it’s all possible. We found it super easy to write new features or even add parts of new features to already-existing JS code, writing everything in TypeScript.

We also rewrote some JS files that were used from multiple places in the app to TypeScript. As an example of JS-TS coexistence, I’m presenting below the potential .ts source code you might have. It contains both old, legacy JS code when we used module.exports and prototype to expose various services for data fetching, as well as a brand-new, nicely-exported TypeScript class:

Such code can of course be in separate files, but it only shows how good TS and JS can coexist together. You can keep your old code working, while implementing anything new in TypeScript.

Flexibility in partial migrating to TypeScript

It turns out that choosing to partially move our web project to TypeScript was a great decision. The team wouldn’t be so happy and enthusiastic about TS if we told them to move legacy Backbone code to TypeScript. Instead, we gave them a nice tool which can be used for all new stuff. Also, if someone likes the idea and wants to move already-existing JS file to TS, he or she is welcome to do so.

That’s how we are still migrating our project to TypeScript, without any hustle and frustration

Wisdom of TypeScript

I’m positively surprised by TypeScript almost every day. At some point I get to the issue that seems hard to be solved or quite non-standard. Then I find a solution online and it makes me really impressed about the job the community and Microsoft has been doing around the language.

These are sometimes small, but smart things. Recently we got surprised by keyof, which lets you get names of the allowed properties of your type. Generally the typing system is really advanced and impressive. For some it can be a disadvantage, but I think it gives an enormous flexibility.

This is somehow the JavaScript you-can-do-whatever-you-want philosophy smuggled into TypeScript But in a much smarter way. I’m sure that when you start working with TypeScript you’ll get what I mean by its wisdom

Small effort, huge benefits

Last, but not least, I must admit that migrating to TypeScript was quite an easy and smooth process. The value for the effort is huge. You get a typed world with very little work.

Migrating to TypeScript struggles

During the migration process we met few difficulties. Some of them we managed to solve fully or partially. If you have any better ideas on these things, feel free to let me know in the comments.

Complexity of webpack configuration

When switching to TypeScript we had few issues with webpack configuration. We have used babel-loader before for transpiling JavaScript and initially we wanted to keep it in the TS compilation process. We first tried to keep babel-loader for JS(X) files and use ts-loader for TS(X) files, but it didn’t work – we were getting weird compilation errors.

Then we tried to compile everything using ts-loader and then recompile it again using babel to ensure (as we initially thought would be wise) backwards compatibility. We also couldn’t make it working.

Finally, we decided to compile everything – both JavaScript and TypeScript files – using ts-loader (including React files). It worked, except source code maps. When we tried to debug in Chrome console it seemed the source code is not refreshing properly after rebuilding. Breakpoints were often not hit and the debugging didn’t seem right.

After a bit of struggling we found a solution. We set devtool webpack option to eval-source-map and configured source-map-loader for .js files. Finally, the proper part of webpack config looks as follows:

So far we also haven’t noticed any issues related to backwards compatibility that were theoretically solved by babel. TypeScript compiler does its job very well.

Complicated JS -> TS refactoring

I found out that JS to TS refactoring is not always an easy task. Some things that are allowed by JavaScript are not valid in TypeScript. In most cases it means that something was wrong with your JavaScript code, but we all know how it is with legacy code refactoring

As an example, we had several functions that we added to a String prototype in JavaScript:

Such code becomes invalid in TypeScript:

A non-obvious solution to that issue is to extend String interface by declaring typed functions you want to add:

There are more subtle difficulties like that you can meet while migrating JS code to TypeScript. However, in the end it gives you a possibility to make your codebase better.

Keeping view models in sync

An issue I didn’t think about before migrating to TypeScript was a need to keep frontend and backend view models in sync.

One of the first things you’d like to have in your TypeScript codebase is to have as much typed data as possible. We use .NET and C# as the backend of our application. ASP.NET MVC controllers returned the strongly-typed objects into the previously chaotic and untyped JS world. Now we are strongly-typed with TypeScript, so we’d like all this data typed as well

Here comes the problem. First of all our C# data models which we returned from the controllers were not the best. In most cases we returned a DTO object which contained many properties from which only few were used by JavaScript code. We never saw this problem, because in JS we just dynamically typed properties names we wanted to use. We didn’t see how much of not needed data is sent from ASP controllers to the web browser.

Now with TypeScript we needed to create these objects definitions also in TypeScript. Having a huge DTO object returned from the controller, with another X objects on which this DTO depends, it was a nightmare. It turned out that for a single DTO I had to create 10-15 TypeScript objects just to use 5-10 properties in the frontend code!

That’s the moment when we came to the necessity of creating web view models. The idea is to return a view model from a controller, not the whole DTO object. This view model contains only the data which is needed by TypeScript (frontend).

I think this is nothing new for experienced web developers. However, now comes the question: how do we keep backend (C#) view models in sync with frontend (TypeScript) ones?

Unfortunately, I haven’t found a perfect solution for that. The best method I came up with is… manually keeping these view models in sync.

There’s a C# to TypeScript VS Code extension which allows to paste the copied C# code as its TypeScript equivalent. It makes the job a bit easier. It even has a CLI tool, but it produces a single .ts file from a single .cs file. If you have multiple objects in a single C# file it will produce a single TypeScript file with all these objects. If any of those objects is used in other files (unfortunately we have many of such cases), these dependencies will not be automatically added as imports in the auto-generated .ts files.

However, I don’t find it very problematic for now. As soon as the TS view models are created, we just need to update them as often as we update C# view models. I think this is a very common issue so if you know any better solution here – please share in the comments

Migrating to TypeScript – summary

Migrating to TypeScript has been a very interesting and rewarding process. Compared to vanilla JavaScript, TypeScript lets programmers see many problems. This allows to see how bad our codebase was. We even realized that our server-side C# code was not the best (see the section about view models above). Thanks to introducing TypeScript we improved a lot of our JavaScript and C# code, including its architecture.

I think that TypeScript uses many simple concepts under the hood and it makes a lot of things possible (see keyof or unknown). In many cases TypeScript lets you do something, but doesn’t force you to do it. That’s the beauty of this typed JavaScript world

The post Is It Worth Migrating to TypeScript? appeared first on CodeJourney.net.

How will this possibility change the way we write C#? Why is it being introduced? I’ll try to address these questions today

Interfaces today

As we all know from the current version of C#, interfaces allow to define a kind of contract, which must be respected by a class implementing it. Today interfaces can only contain definitions of methods (with no body). These methods are then actually implemented by concrete classes. If a class doesn’t implement all of its interface’s methods, compiler produces an error.

What’s problematic in this approach? Assuming that you have the following interface and class(es) implementing it:

With time, you may want to extend IDeveloper interface by adding a new method, for instance:

Now you have a problem, because the new method must be implemented in all places where the interface was used. Compiler gives you an error as long as it’s not done:

If your interface is used in many places, also by another teams or developers (which is often the case in reality), this is a breaking change

It may be really painful, depending on how extensively your interface is used. In any case, all classes based on the IDeveloper interface must implement the new LearnNewLanguage(string language) method. Only then the code compiles.

One of the reasons for introducing into C# default interface methods is to avoid such breaking changes scenarios

Default Interface Methods

As we can read in the feature’s design notes, an inspiration for it is a similar concept already alive in Java – Default Methods.

The main idea of this new C# feature is a possibility to provide a default implementation of an interface’s method.

Realization in C# 8.0

In our example using C# 8.0 we’ll be able to implement it as follows:

In that case, our class implementing the IDeveloper interface can legally not implement this new method and there will be no compilation error:

Notice that it only works when BackendDev is contextually treated as IDeveloper. It means that a class doesn’t inherit members from the interfaces it implements:

What about multiple inheritance?

As some of you probably realized, this new feature exposes C# to a multiple inheritance problem (also known as Diamond of Death). So far C# didn’t have this issue, because we can only inherit from a single class. We can implement multiple interfaces, but so far the interfaces couldn’t provide methods’ implementation. Because of that, there was no Diamond of Death possible. Soon it’s gonna change

Diamond of Death in C# 8

In case of C# default interface methods we may illustrate this issue with the following code:

Please note that the syntax or places in which compiler generates errors may still change in the final feature’s version.

To better illustrate this Diamond of Death example, take a look at the following diagram:

The question is: which method should be called in such case?

Solution: most specific override rule

C# 8.0 will solve this issue by introducing the most specific override rule. It means that in our case illustrated above, the compiler will issue an error and won’t let us do this.

To avoid this ambiguity, we’ll be forced to implement or override LearnNewLanguage(string language) in IFullStackDev interface. Only then it will be considered the most specific version of the method in the interfaces hierarchy we have. It will then be used when calling the method on objects contextually treated as instances of IFullStackDev. We could also implement it directly in the Dev class and use the class (not interface) type. It would then call the most specific method from the class. This way multiple inheritance issue will be eliminated.

Compiler for the rescue

There are a lot of other potential ambiguity scenarios that may take place after introducing into C# default interface methods. You can check all of them with potential solutions well-discussed on GitHub.

The general assumption is that all code which may lead to issues related to default interface methods implementations is detected by the compiler. In effect, we should get appropriate errors when compiling the source code. That way, programmer can fix all potential conflicts directly when these arise.

What about .NET Framework?

What’s interesting with default interface methods is that it requres changes in the runtime. According to current assumptions, it means that this feature will not work with .NET Framework! Only CoreCLR and Mono stack runtimes are going to receive these new updates.

Summary

As the motivation for introducing into C# default interface methods the language team members mention possibility to interact with some Android and iOS APIs, which already support such feature. They also claim that C# will get the traits programming language feature with default interface methods.

In my opinion this is the most controversial from all C# 8.0 new features. It completely changes something which was obviousness for the developers for years. Probably we’ll see less breaking changes issues when the interfaces are extended, but looking on the list of issues and edge cases it produces… Maybe assuming it already works in a similar way in Java we should just accept it?

Another interesting, .NET-specific aspect is that this feature will not work with .NET Framework. It’s probably the very first moment when the difference in pace between .NET Core and Framework is so explicit.

I’m also very curious about the performance implications of default interface methods. I’ll for sure be following this issue on GitHub to see how it evolves

What do you think? Is it a good idea to introduce default interface methods into C#?

The post C# 8: Default Interface Methods Implementation appeared first on CodeJourney.net.

Let’s see how this tiny feature is supposed to make our life easier

Goal of slicing

The main purpose of introducing slicing into the language is to make working with arrays and strings easier.

Currently, when you want to retrieve a fragment of an array (X elements from the array, located for instance in its middle), you can use LINQ, i.e. combination of Take and Skip methods. You can also create some extension method to provide kind of slicing.

To illustrate the current way, using LINQ to retrieve only 2nd, 3rd and 4th elements of an array looks as follows:

C# community and designers decided it’s not convenient enough, so are now adding to C# 8 indexes and ranges (in order to provide slicing)

Index

C# 8.0 comes along with a new object – System.Index. It’s a structure internally and looks as follows:

What’s interesting here, is that the constructor takes the value of the index and boolean flag fromEnd. Let’s see how we can use it in practice:

While the first printed value is nothing special, as you can see we can now use the hat operator (^) in order to index from the end. The following also works:

It means that the ^ operator is a syntactic sugar for Index. I allowed myself to check the IL produced:

As we suspected – an instance of Index is created, passing 3 as value and true as fromEnd (see the constructor parameters above).

Range

Another concept which uses Indexes is a new structural data type – System.Range:

As you can see, it really uses Indexes. We can even try creating it on our own:

This doesn’t really make extracting data from the arrays better than Skip-Take LINQ, does it?

Fortunately, there’s another friendly C# language element introduced called range expression. It can be written as x..y and used directly for indexing:

This looks much better! Let’s see how C# compiler translated our 2 lines of code by looking at the pseudo-C# IL produced:

Even though we could achieve the same with much less LINQ, C# compiler does a lot of stuff for us, keeping our code simpler to grasp.

Ranges in strings

All these operations apply also to strings:

Ranges in foreach loop

Next interesting usage is in the foreach loop:

Summary

I see these “little” C# 8 indexes and ranges as another helpful feature. It’s less breaking and controversial than nullable reference types, still making us write less C# code in the future.

If you’d like to dig the feature even more, I encourage you to read the discussions about it on GitHub, which I always find very interesting

Developers, what do you think about C# 8 indexes and ranges?

The post C# 8: Slicing with Indexes and Ranges appeared first on CodeJourney.net.

Learn about building C# 8.0

C# 8.0 is going to be the next major release of C# language. It should be released by the same time as .NET Core 3.0.

What I find very interesting is C# language GitHub repository. Among others, you can find there very interesting notes from C# language design meetings If you filter well, you can also list so called “proposals”, which are current candidates for new C#’s version (or sub-versions) features. By clicking here you can list C# 8.0 candidates.

I will publish a separate post regarding each feature which I find particularly interesting

Nullable reference types

First of the C# 8.0 features I’d like to discuss are nullable reference types. It seems it’s going to change the way we write our code, so it’s worth knowing this feature.

A bit of history – NullReferenceException

Consider the following code:

Guess what happens after executing this as a console app? Of course, our favorite NullReferenceException is thrown:

In this case, jsDev.LastName is of course set to null.

NullReferenceException has been a nightmare for thousands of developers (and users) for many years. What if, in the cases like our example, we knew before that in this place our object might be null?

New world – #nullable enable

For that purpose, C# development team is introducing nullable reference types. In essence, it makes reference types (like string) non-nullable! However to not be a tough nut to crack, all issues related to assigning null value to non-nullable reference types are presented as warnings, not errors.

In order to use this feature, you need to enable it. You can do it with a preprocessor directive #nullable enabled. We can do it directly in the source code file. In the future, it should also be possible to enable it on project level.

Notice what happens when we enable it in our example:

We’re still able to compile, but this nice warning is displayed As soon as we initialize LastName property in the constructor, the warning disappears:

If you try to cheat, it still works like a charm :

But hey… what if you actually want null in this particular string? You need to explicitly mark your reference type variable as nullable. You probably recall nullable value types like int?, don’t you (read this post if you don’t remember the difference between value and reference types)? Now you can do the same with non-nullable reference types:

Nonetheless, in such case, the compiler still takes care of us:

The final fix is quite obvious – we need to check for null first:

At this stage all warnings finally disappear. You can find the finished source code here.

Nullable reference types in IL

The only thing I found in the IL code compiled from source code with #nullable enabled directive was NullableAttribute applied to properties:

It seems that nullable reference types are implemented by applying this attribute to variables, which is only used by the compiler (runtime is not affected).

Summary

I’m really excited about nullable reference types in C# 8. I personally feel that it even introduces some clarity in the language – we’ll have explicit declarations for nullable value and reference types. However, in more complex scenarios it may bring some confusion in regards to reference types and using “?” character (like generics or collections – see Jon Skeet’s post for more details). For sure it’s a significant step towards eliminating issues with exceptions caused by null references.

What do you think about nullable reference types? Is it a good direction in which C# language is going? Share your thoughts in the comments!

The post C# 8: Nullable Reference Types appeared first on CodeJourney.net.