As you can see, there are some [cached] mentions there in a few places and no [code generated] statements at all. The effect is that your bundles are not rebuilt at all. In order to have them refreshed, you need to restart the building process, which takes time and makes your development flow painful. If you want to know how to solve that problem, read on ?

webpack watch cached files

We have struggled with this issue for quite some time. It starts with launching webpack with --watch option. Such build script can be defined in your package.json in the following or similar way:

The effect you would expect is for webpack to rebuild your bundles as soon as you make any change in the source code.

When the webpack watch cached issue occurs, the first change you make in a file is properly reloaded by webpack and looks similarly to that:

However, as soon as you change the file for the second time, the output looks less promising:

As soon as you see some of these [cached] things, it probably means that webpack cached something and did not generate new bundles. Especially if there are no [built] and [code generated] statements in the output. You notice that your files are not refreshed, so your last change is not reflected in JS bundles ?

Hotfix: disable webpack cache

The first hotfix solution – especially if you can’t easily find the cause – is to disable webpack cache completely. In order to do that, you should set cache to false in your webpack configuration file:

This will work, and webpack should now rebuild your bundles on every source change. However, it comes with a significant performance cost. Disabling the cache will make webpack actually rebuilding all your bundles on each change. This solution is actually a shortcut for restarting the build from scratch. Not what we really want ? Let’s see how to find the cause and solve webpack watch cached issue properly.

Wrong casing – the real cause of webpack watch cached issue

In our case, the problem turned out to basically be wrong casing when importing stuff.

The general advice is to find how given file you are modifying is entered into your webpack’s build flow. It can be imported or required directly. Maybe it’s used via webpack alias. I know these are quite general statements, so I’ll show you two examples.

Wrong casing in import

First, we had a problem of webpack watch not refreshing bundles after making changes in a single file. This file is named questionnaireCorrectTemplate.tsx. It exports a single React component called QuestionnaireCorrectTemplate.

In order to use this component, we imported it in another file in the following way:

Have you already noticed the problem? Note that the import contains the module name with capital letter: “./QuestionnaireCorrectTemplate”. As soon as we changed it to a small letter, so exactly as the questionnaireCorrectTemplate.tsx file’s name:

Everything started to magically work ? Since this change, webpack watch is properly rebuilding our bundles after changes in the affected file ?

Wrong casing in webpack alias

We had another issue with webpack not refreshing the bundles when we made changes in a Site.css file. This is a file in which we store custom CSS for our React app. The issue was very similar to the previous one. After starting webpack watch, the first modification of Site.css file triggered a proper rebuild of bundles:

However, all subsequent modifications to the Site.css file causes the webpack watch cached issue:

The reason was wrong casing again. However, this time we found out that the Site.css file was included as an alias in webpack configuration file:

I guess you can already see what is the problem ? The file was included as site.css, instead of Site.css. As soon as we changed this part of the webpack.config.js file to the one with proper casing:

Everything started to work correctly. Since this change, webpack watch correctly refreshes the bundles after each modification of Site.css file ?

Webpack watch cached – summary

I hope this article helps you solve your webpack watch refreshing issue ? Webpack is still kind of magical tool for me and it surprises me very often. Such issues can be really painful – that’s why I wanted to share our solution to this problem with you.

The general advice is to find how the problematic file is imported/required/added to webpack build flow. It’s very probably that you have the wrong casing somewhere. I hope it saves you some pain one day!

The post Webpack Watch Cached And Not Refreshing Bundles appeared first on Yumasoft.

Even tough, you really knew that the name property exists on the person object? How did you solve this problem? Did you cast the variable to the expected type?

If the answer to at least one of those questions is yes, you might read on. There are better ways of determining the type of local variable in TypeScript. What’s more, TS compiler does a lot of stuff for us by leveraging types narrowing. In this article, we are going to see how it works and how it can be useful ?

TypeScript types narrowing – what is that?

One of the goals of TypeScript is to make writing JavaScript code better and more secure by adding the typing system. However, we don’t want the typing system to be problematic and making us to use the dirty haxes like all the time casting our variables explicitly, do we? ?

First, we need to understand that TypeScript does a lot of stuff in order to ensure we work with the most specific type as possible. Basically, if the exact type of local variable can be determined, TS compiler tries to do that.

Imagine such a function:

In vanilla JS, such code would of course compile. But in our case, TypeScript sees a problem:

The compiler is right here. Our parameter is either string or number, so the length property may not be available if someone passes a number.

You might have already been in such situations. What did you do? Well, sometimes when the code is more complex, and you just know that the variable contains the requested property, it might be tempting to cast:

Of course, we will satisfy the compiler here. But does that make our code any more safe than the previous version? Not at all.

In our example, based on the code we have written, TypeScript is not able to determine the exact type of variable. We can help it by using type guards. We will talk about them in details in a separate article. However, for now it’s enough to know that the language has some built-in type guards – one of them is typeof. Let’s use it in our function:

That’s cool, TS compiler doesn’t complain anymore. But how does it work? Our code is still accessing variable.length directly, there’s no casting there.

Notice what your IDE tells you when you hover your mouse over the variable in the first if branch after checking if the type is string:

and also what it tells you when hovering over variable in the else block:

Wow! The IDE magically knows what’s the exact type of our locally scoped variable! ?

This magic is called types narrowing. TypeScript compiler does many things to ensure that the type of local variable you work with is of the most specific type possible. It is based on the complex analysis of the source code, especially the code surrounding the place in which the local variable is used.

in keyword in types narrowing

Let’s take a look at this code now:

Let’s say we have a variable which may either be Employee or Manager:

In that place, TypeScript can’t say whether person is Employee or Manager.

Maybe you’ve used the in keyword for determining types before. Types narrowing also works with in keyword:

As you can see, TypeScript analyzed the flow, and it noticed that in the first if block we check whether the person object contains the employees property. If it does, the compiler known it must be Manager, not Employee. Cool, isn’t it? ?

Narrowing and equality operator

Another interesting application of TypeScript types narrowing is using the equality operator:

Notice how TypeScript determines the type of variables based on the === operator. If both parameters are equal, they must be both strings.

TypeScript types narrowing – summary

Narrowing in TypeScript is a very power feature of the language. I just showed you some simple examples, so you can grasp the idea and notice how much TS compiler does to ensure your type is the correct one.

If you’re interested, you can read much more about this in TypeScript docs. It’s however worth knowing how TypeScript compiler works and how you should properly check for types in your code. Remember that using any or explicit casting should be your last resort ?

The post How Does TypeScript Types Narrowing Work? appeared first on Yumasoft.

Prototypes

You may consider not doing TDD with prototypes. By prototype, I mean an app that will most probably be thrown away or completely changed very soon. It may be created when you are experimenting with some technology/framework or are just asked to conduct research on something.

TDD gives you a high code/flow coverage, which may need to be changed in case of prototype projects. If you are in such situation, consider resigning from TDD at this stage.

Short living apps

Similarly to prototypes, short living solutions might be the ones where TDD is not the best fit. It applies to one-time-use apps or scripts which are supposed to do one thing well and quickly.

Short living apps are the ones where you may consider not using Test Driven Development. I’d even argue whether you need any kind of tests for such programs. Testing such apps or even scripts may be art for art’s sake. If something is supposed to realize a given task without fireworks (like reusability, maintenance etc.), I wouldn’t bother with testing it. It’s better to focus on solving your current, short-lived problem than on practicing the profound TDD idea ?

Unclear requirements

One of the reasons not to use TDD might be unclear requirements. The idea of writing tests in Test Driven Development is to define the expected outcomes for predefined incomes. As we said in the previous article, Test Driven Development can help spot the edge cases and make the business requirements more close to the code. However, if you don’t have these requirements defined, TDD might be a waste of time (at this stage). If the requirements actually arrive or are completely changed, your significant set of tests will need to be changed or even removed.

MVP

If you’re creating an MVP, with very short time and budget, TDD might not be worth the struggle. It’s probably better to resign from using TDD in that case. You should rather focus on your product and the business value it needs to deliver. TDD might slow down the delivery time, which, in case of MVPs, can be critical. It’s better to deliver the minimum viable product without TDD than to not deliver it with TDD ?

However, remember to add some tests, even post-factum. MVPs have a high chance of survival, so you’d want your final product to be tested and testable. You need to find a good balance here, not to make your solution completely untestable when it’s ready for production use.

Tests writing beginner

If you are a total beginner in writing tests in general, Test Driven Development might not be the best approach to start with. You may consider not to use TDD at the beginning of your testing journey.

To make Test Driven Development effective, you should be able to write tests quickly and efficiently. Starting to learn software testing with Test Driven Development may make you feel overwhelmed and discouraged. If you’re a beginner, I suggest to first write some unit tests, get familiar with that and then try to learn Test Driven Development.

It would be great if you can find some smaller and well-defined task to start with TDD. If you don’t have such tasks, try solving one of the programming katas (e.g. this one) with TDD.

When not to use TDD – summary

Like everything, TDD is not a gold standard for every possible case. It should be used as often as possible, but not always. Remember to always weight the gains and losses from using Test Driven Development in a given project or application at a given time.

What’s your experience with Test Driven Development? Can you list any more cases where it’s not worth using it? Share your thoughts in the comments below!

The post When Not To Use TDD? appeared first on Yumasoft.

Moving design into code

With test driven development, you create your tests before writing production code*.

Having that in mind, one of the benefits of using TDD is that you need to move your design requirements into code before you even write a single line of business logic.

It means that you need to spend time thinking about good names for your tests. I often create empty tests straightaway after staring to work on a task. Spending time to create well-named test methods can help you quickly spot missing parts in the design.

*By production code I mean the actual business logic except the tests’ code. This is only to differentiate here, but I personally consider my tests part of the production code in real life. Tests are as important as all the code.

Finding edge cases

Going further, if you create many empty tests with well-thought names, you will surely find many edge cases. Thanks to test driven development, you’ll verify the business requirements by your code without writing even a single line of it. Discovering edge cases and boundary conditions will let you clarify the requirements or even change/adjust them before any production code is written ?

Structuring your code beforehand

You’ll see that TDD forces you to think about the code you’re about to write beforehand. You’re going to think about production code to-be-written: how and where to add it, what methods, parameters and classes are needed. Thanks to that, you can quickly notice that maybe the place you’d normally place the new code in is not the best choice. Maybe it requires too much changing instead of modifying.

Such approach leads to taking and rethinking architectural and structural decisions before writing a single line of production code. In the end, it saves you a lot of time. Without TDD, you’d probably just add this new code where you thought it’s appropriate and struggle to refactor it later. And refactoring without tests is dangerous ?

Allowing to refactor

Test driven development is based on red-green-refactor cycle. As soon as your test is green, you can safely (for sure much more safely than without tests, especially if you combine TDD with mutation testing) refactor the code you’ve just written.

In the end, the quality of your code is much higher than it would be without tests. You don’t feel the fear of refactoring, which is a common blocker for improving code quality in legacy systems.

Making implementation very easy

When you move from red to green phases of TDD, it’s time for implementation. From my experience, writing production code that satisfies TDD-produced tests is very easy.

I find it much easier than writing code not covered by TDD-based tests. You exactly know what to do and which tests must pass. Thanks to that, your implementation is minimal – it should only make the test(s) green.

Creating current code documentation

Implementing a new feature with test driven development will leave you with a comprehensive set of tests. From my experience, I write few times more tests with TDD than in a “traditional” tests-after-code mode.

As a nice side effect, you’re building and growing the only possible, current documentation of your code – set of your tests. Only tests can tell you the truth about your code. It can’t be achieved with any other kind of documentation. Notice one more advantage – you’re creating documentation… without writing any documentation! ?

Current, well-named tests are very helpful not only for developers, but also for the so-called business people.

Spotting architectural problems

Last but not least, test driven development helps to solve application’s architectural problems. Tests should be relatively easy to write. If the test is hard to write before production code exists, it might mean that the architecture of your solution is wrong. There’s a problem somewhere that should be addressed.

That’s why it’s very important to start working with TDD as early as possible in your project. There might be some cases where TDD it not suitable (maybe I’ll write a separate article about it ?), but in quite mature and stable projects, it should be a gold standard. Altering the architecture is much easier early in the project.

The post 7 Reasons To Start Doing Test Driven Development appeared first on Yumasoft.

In this article, I’m sharing how this can be done ? It will also be useful if you use another testing framework than NUnit, but the examples are based on it.

Starting point

You can find the code accompanying this article here: https://github.com/dsibinski/cypress-csharp-example

Our starting point is a React application with Cypress tests:

I assume that your tests specs are placed within cypress/integration folder. The only spec we have is called submit_spec.ts and it placed in a subfolder called form.

Now imagine, that your backend is written in C#. Maybe you’d like to perform some data initialization before Cypress tests are executed.

In our case, we have a C# backend, and we’ve already had a mechanism for running integration tests. This mechanism runs our server app with an in-memory database, which makes the maintenance of tests very easy.

We wanted to use the same mechanism for our new, E2E Cypress tests. It means that we would be able to write some C# initialization code (data creation mostly) and then run Cypress tests from NUnit test.

What we want to achieve is to have a C#-Cypress NUnit test look as follows:

Let’s now see how we can implement the RunCypressTest method ?

Implementing a method to run Cypress tests from NUnit

To make things easier, let’s create a base class all our test classes can use. We’ll call it CypressTestsBase and add a RunCypressTest method to it:

This code does the job. Few interesting parts:

• Line 12 – I’m getting there the path to the web app workspace where npx cypress run command can be executed. It might be more complicated in your scenario, so you should adjust accordingly here
• Lines 13-20: thanks to setting RedirectStandardInput to true, we can later execute a custom command via cmd; setting RedirectStandardOutput to true allows us to write everything npx cypress run command does to NUnit test’s output
• Line 28: TestContext.Out.WriteLine(cypressProcessOutput); actually writes the Cypress output to NUnit test result
• Line 29: here we handle errors during Cypress execution. npx cypress run executed via cmd will return a code different from 0 if anything goes wrong.

We can now change FormTests class to run its corresponding Cypress test:

Finally, it allows to run our C# test, which then runs its corresponding Cypress spec and prints the output:

Cypress errors in NUnit result

Let’s see what happens if something is broken on Cypress/web app’s side. Let’s run our test, but with our web app not running.

The NUnit test fails, and we can clearly see what was wrong:

You will see similar errors if something goes wrong in a Cypress test. Cypress also saves compressed videos and screenshots, so if something goes wrong, diagnosing such failed tests is very easy.

Summary

I hope you found this article on how to run Cypress tests from NUnit useful. Remember that it not only works with NUnit – it will be suitable for any testing framework. You might need to adjust some parts of the solution, e.g. printing the results to the test result’s output.

This solution allowed us to improve our testing by adding a new type of tests to our pipeline. Right next to proper naming and mutation testing, E2E tests add another layer of security and improve the quality of our software.

Once more, you can find the complete source code here. If you want, feel free to copy it and change it according to your needs ?

The post Run Cypress Tests From NUnit Test (C#) appeared first on Yumasoft.

We will go through a step-by-step example in building our own custom collection to see how all that works. Let’s dive in! ?

Throughout this article, I’m working with a Unit Tests project using .NET 5, C# 9.0 and NUnit. It makes it easier to play with the code on your own. We can create our custom collection and at the same time try it out in a foreach loop in a test method. I recommend this approach for testing out various programming concepts for yourself ?

Custom collection implementing IEnumerable<T>

First, we want to implement our own, custom collection in C#. The most obvious solution is to implement IEnumerable<T> interface. Our IDE will require our class to implement IEnumerator GetEnumerator() and IEnumerator IEnumerable.GetEnumerator() methods, so let’s do that:

Of course, this is just an example to satisfy the foreach loop, so we won’t care about the actual implementation of these methods ?

Custom collection implemented in such a way can be used in foreach loop:

Does foreach require IEnumerable?

Let’s try to get rid of implementing IEnumerable interface. As soon as we do it, our IDE complains:

Let’s try to remove IEnumerable.GetEnumerator() method completely, so our custom collection looks as follows:

Now guess what – we can still use MyCollection within the foreach loop!

So you already know that, when asked during an interview whether foreach needs a collection to implement IEnumerable, the answer is no ?

Custom IEnumerator

Currently, our collection has a single GetEnumerator() method returning IEnumerator<MyObject>. We already know that this method is needed in a collection to be able to use it within a foreach loop.

However, let’s work on what this method returns. We’ll implement our custom IEnumerator. Again – the most obvious solution is to create a class implementing IEnumerator<T> interface:

That’s the implementation proposed by the IDE (Rider). We can now change our collection to use this custom enumerator. See that it can still be used within foreach:

So far, so good. But why all these methods in MyObjectEnumerator? ?

Does foreach need an enumerator implementing IEnumerator?

If we remove inheritance from IEnumerator from MyObjectEnumerator, the IDE only complains about IEnumerator.Current property, so let’s get rid of it. Our custom enumerator now looks as follows:

Yeah, you guessed it again – we can still use our collection in a foreach loop ?

However… Does our custom enumerator really needs all of these stuff: MoveNext(), Reset(), Dispose() and MyObject Current ? Let’s remove all of them and see what our IDE tells us:

That’s the error from IDE when trying to iterate through our custom collection in foreach:

Type ‘ForeachFun.MyCollection’ cannot be used in ‘foreach’ statement because it neither implements ‘IEnumerable’ or ‘IEnumerable’, nor has suitable ‘GetEnumerator’ method which return type has ‘Current’ property and ‘MoveNext’ method

This error actually tells us everything. This is the ultimate answer to the legendary C# interview question: “What does a collection need to be able to use it in foreach loop?”. In other words: “Is it necessary for a collection to implement IEnumerable to use it in a foreach loop?”

The answer is: a collection needs to have a GetEnumerator() method returning an object of type having Current property and bool MoveNext() method. No interfaces are required anywhere here ?

The compiler uses duck typing to find these two necessary ingredients of the type returned from GetEnumerator(). It means that is looks for these properties by text. Later, depending on the type of Current property, a single element inside the foreach is typed accordingly. Only if this duck searching fails, the compiler checks whether the collection implements the interfaces.

In the end, this is our simplest and fully legit code (except the actual implementations of the methods, which is out of scope of this article):

Summary

I hope you got to know something new about foreach loop from this article. This may not sound like a knowledge you’d need on a daily basis, but it’s worth knowing how stuff works under the hood ? Plus, you can always score a point during your next interview ?!

The post Foreach, IEnumerable and IEnumerator in C# appeared first on Yumasoft.

At Yumasoft, we believe that testing is an inseparable part of software development. Mutation testing, which recently got a bit more attention in programming communities, is a great way of improving our tests. In today’s article, we’re exploring what mutation testing is and why everyone should be using it ?

What is mutation testing?

To make it clear, mutation testing isn’t just a new type of tests you can write. At least not in a casual sense of a test ?

Mutation testing is a technique for validating your already-existing tests. They basically allow to test our tests.

Mutation tests are not for people who don’t write tests (go away, we don’t like you!). They are for people who care about testing and want to make their tests better.

How does mutation testing work?

Mutation tests introduce mutations into our source code under tests (you can call it production code). Mutations can be any changes in the source code you can think of. Let it be a modification of a condition within an if statement, replacement of a string value or change of an arithmetic operator – you name it. All you need to know is that mutation testing is based on automatically introducing changes to your source code.

Our codebase with such a change (a single one) introduced is called a mutant. It makes sense – our production code is now somehow mutated.

What happens with such a mutant then? All our existing tests are executed against it. Such tests’ execution may produce two outcomes:

• all tests have passed – that’s a bad scenario. It means that our mutant has survived. In other words, it means that a modification of our production source code wasn’t detected by our tests suite
• at least one test has failed – that’s a good scenario. It means that our mutant has been killed. This is what we want, because it means our tests are well-covering and detect changes in the production code.

You can see the flow of mutation testing on the following schema:

Example of mutation tests

To make mutation tests more practical, let’s see an example. We’ll be using StrykerJS for production code written in TypeScript.

This is our production code:

We have of course written some tests for this code. When we execute these tests with jest, we can see the following result:

So we have 100% coverage for DiscountApplier class! What’s more, we have 100% statements, branch, functions and line coverage! This sounds perfect, right? Why should we bother more? ?

Let’s deep dive and run StrykerJS mutator against our app. After installing and configuring Stryker properly, we can execute npx stryker run command. That’s the final result:

Whoooaa… we see here some 82.14% value, not 100% anymore ? This is what I call mutant coverage.

Remember what we said above about survived and killed mutants? Pay attention to our mutations results above – we have 46 mutants killed, but 10 of them survived. It means that we have a potential to add more tests to cover these scenarios.

We will not be going through each mutant and adding the test for it in this article, but I can tell you what these results can give you. In the beginning, when our mutant coverage was 82.14% with 10 mutants survived, we had 6 unit tests written for DiscountApplier class. In the end, after working out and killing each mutant one-by-one, we finished with 12 unit tests and 100% mutant coverage.

In 10 minutes (time needed to add these 6 tests), I got twice as many unit tests as in the beginning. Now, both “traditional” and mutant coverages are 100%. My confidence in refactoring or modifying the production code is much higher now. Notice that we got this all “for free”. Mutation testing tool (StrykerJS in that case) did everything for us. This is huge! ?

How to start writing mutation tests

Just find a proper mutation testing tool for the framework/programming language you work with. Here are a few most popular examples:

• JavaScript/TypeScript/C#/Scala: Stryker mutator
• Ruby: mutant
• Java: Pitest
• PHP: Infection

Go straight to the docs of your tool of choice and start mutating ? The messages about each mutant are very clear, so adding new tests to kill them will be very easy. It’s like someone sitting next to you and telling you exactly what test you should add for your code. That’s actually a pretty decent solution for anyone who doesn’t like writing tests ?

I don’t see any reason why anyone would not use mutation testing. It’s such a great tooling that I don’t see any disadvantages in using it. It can greatly help you with TDD as well as an additional “layer” of inventing new test cases and patching your code. Believe me, you’ll see the benefits straightaway.

So – download one of the mutation tools and make your tests bulletproof today ? Or at least see how bad they are now ?

The post Make Your Tests Bulletproof With Mutation Testing appeared first on Yumasoft.

But what you actually want is the real object present there:

After reading this article, you will know how to achieve that ?

JSON.NET circular references are the issue

Let’s take a look at our problematic JSON response object once again:

$ref: "1" is basically a reference to another object, which has already been serialized. In that case, the BestFriend field references the first element of the result array with $id: "1". It turns out that these are JSON.NET circular references. However, you don’t want these references in your client-side JS code – you need the actual objects to work with.

I struggled with this issue some time ago in my JavaScript code. In the beginning, I had no idea it might come from the fact that JSON.NET is used for serialization (thanks to our colleague Rafał for pointing that out to me ?). Let’s see what exactly happens here and why.

JSON.NET serialization

The JS example presented above shows a JSON result received from the following ASP.NET controller method:

This is the full content of json string after serialization:

Of course, this is great that JSON.NET does that. Why would we repeat the same objects multiple times in JSONs? The optimization here is that the same objects are serialized once and referenced from all places that use them.

However, if such JSONs are sent to the browser, fields with refs are of no use. We need the actual objects to be there, so we can process the results correctly using JavaScript.

Solution 1: fix the issue by reconfiguring JSON.NET serializer

The first obvious solution could be to configure JSON.NET to not use its optimization for references. Quickly searching through its documentation, we find that PreserveReferencesHandling setting is responsible for that.

If we change our controller’s code and serialize objects with PreserveReferencesHandling set to None:

Our JSON file will look exactly as we’d expect:

However, why would we disable JSON.NET circular references? This optimization can sometimes save us huge amounts of data to be sent over the wire. If you have thousands of objects, it might not make sense in sending them all to the client-side code.

You may also have no control of the backend/API you receive the data from. It might as well be dangerous to change the JSON serialization settings, especially if you work on a big project.

If reconfiguration of JSON.NET circular references serialization is not possible in your case, see the other solution (which we also use).

Solution 2: resolve circular references using JavaScript

So we are back to this state in JavaScript:

What we want is to have the full objects’ contents instead of $ref elements in our JSON result.

In fact, all the data we need is already there. The first element of the array with $id: "1" is object that should be put in place of all $ref: "1" references.

As you can imagine, this requires a mechanism that would traverse the results tree and replace all these values according to IDs of the referenced objects.

Fortunately, we don’t need to implement it ourselves. There are few implementations of such a tool, circulating the web.

We use something called JsonNetDecycle which we found few years back already. I noticed there’s a new version of it ported to TypeScript: jsonNetDecycle.ts. It doesn’t provide full type support as it is a few years old already, and I didn’t try it. But you can if you use TypeScript ? There’s also a cycle.js solution available here and recommended by many folks. I believe it may also solve our issue, but again – this is not what we are using.

The version of the JsonNetDecycle we use is this one. Simply create a new file called JsonNetDecycle.js in your project and copy this Gist’s contents to this file. You can skip the last part starting with (function(console) (line 112) – we won’t need it.

Now, we can use the exported JsonNetDecycle.retrocycle() function to “fix” our JSON:

Let’s see whether this works.

This is what we get from the API before resolving JSON.NET circular references:

So we still have references there instead of real objects.

Now let’s see what happens with the result object after executing JsonNetDecycle.retrocycle() on it:

Wohhooa! That’s what we wanted ? There are no circular references in our JSON response anymore!

The post How To Fix JSON.NET Circular References ($ref) In JavaScript appeared first on Yumasoft.

Consequences of bad tests’ names

You may think I’m exaggerating here. Why would I care about naming my tests methods? These are only tests… Let’s not waste time on thinking about such unimportant things. However, before we dig more into that, let’s see how typical badly-named tests look like. Below, I’m presenting the types of badly named tests that I see most often. I also used to name my tests like that ?

Random names

This is what I like the most:

Just random names. Surprisingly, I see that quite often. What does such a list of passing tests tell us? Why do they pass? What do these tests verify? We know nothing about them. We can only see that there are some tests. What they test, how and under what conditions – can’t say ?‍

Tested object described

This is another type of tests I sometimes encounter. A bit better, yet still far from fully informative:

Looking at these tests list, we can at least say a few things:

• there exists a UsersService class which is under tests here
• UsersService has at least two methods: GetUser and Login
• under some unknown conditions, GetUser and Login methods probably work

However, we still don’t know what it actually means that these tests pass. Does it mean that login and getting users are well-tested and work correctly? What conditions need to be met so the user can log in? What parameters do we have to provide to GetUser method to use it properly? Again – we can’t say.

Expected outcome described

Let’s go one step further. A bit improved tests might look as follows:

Someone tried to be a bit more descriptive here. That’s good, isn’t it? ? Let’s try to see how many things we can say about our codebase now:

• there exists a UsersService class which is under tests here
• UsersService has at least two methods: GetUser and Login
• GetUser method returns user data
• GetUser might sometimes throw UserNotFoundException
• Login logs in the user correctly under some conditions
• Login returns a user token
• Login might sometimes throw WrongCredentialsException

We already know much more about our codebase! However, notice that we still often use very uncertain words like “sometimes” or “some”. It doesn’t feel we’re sure about these outcomes. We still don’t know under what conditions these tests pass or exceptions are thrown.

Why badly named tests are bad?

I think you already know that at this point. Badly named tests are confusing. They don’t tell us enough about our codebase. One of the goals of tests is to be a live code documentation. But how can they be if they are very undescriptive? How can we know what happens in case such a test fails:

What do we know looking at that? Why could this test fail? If there’s a non-technical person looking as this result in a CI system while programmers are not around – how can (s)he tell what’s wrong and how to potentially fix that?

This result tells us nothing more than the Login process does not throw WrongCredentialsException. But we don’t know when it should throw this error. What are the conditions that should be met for this exception to be thrown? Again – we can’t say.

Notice that I used the best from all examples we had so far. What if this test was named Test1() and it failed? Does it mean anything? Is it something serious blocking the release of our app, or we can ignore it? ?

I guess you now see very well what I mean by badly named tests. I hope you also understand – and agree ? – that such tests’ names are bad.

Fortunately, we all here write tests, right? ? So, if we are already putting some effort in creating tests, let’s put a bit more to make them informative and useful for others.

Naming tests done well

There are a lot of unit tests naming conventions. You can read about them in many great articles like this one. There’s a lot of discussion around naming tests conventions.

However, independently of which naming strategy you choose, I think a well named test should tell someone who reads its name the following things:

• what is tested (class name)
• which part of it is tested (method name)
• what is the expected result
• what are the conditions for the expected result

Many of tests naming conventions fulfil these 4 requirements.

Let’s come back to our last example of badly named tests (but still its best version):

Let’s use one of the naming conventions I like:

MethodName_Should_ExpectedResult_When_Conditions

Applying this to our tests, the final result is as follows:

Now, for each test, we can see what is tested (UsersService), which part of it (e.g. Login method), what’s the expected result (e.g. ReturnUserToken) and under what conditions (e.g. CorrectUsernameAndPasswordProvided). This is very descriptive and valuable. Now, when something goes wrong:

We know a lot more than before. We can easily see that when wrong credentials are provided, the WrongCredentialsException is not thrown (while it should). It makes it easier to judge whether this is blocking for the release of our app or not. We probably don’t want to let users login with incorrect credentials ?

Another, very important factor for naming your tests well is that the whole team agrees on one naming convention. I think it’s even more important than choosing a particular naming convention. Choose whatever suits you and your team. There are a lot of options, but in the end it doesn’t really matter which one you agree on. Just stick to it and make sure it delivers all value you need.

How naming tests well can help the programmers

Correctly and descriptively named tests can help you as a programmer. Imagine that you are about to introduce a change in UsersService, but you have no idea how it works. The first thing I do in such cases is to open a corresponding tests file and scan all unit tests.

First, I expect that the tests file is named UsersServiceTests, because my team follows a common naming convention. Thanks to that, I can immediately open this class in my IDE and quickly scan all unit tests names:

This tells me a lot about the UsersService. If I want to see only how Login method works, I can easily filter out all tests with names starting with “Login”. Again – thanks to following the naming convention.

The next thing is that when you start making changes to the production code of UsersService and one of the tests fails, you know what’s wrong very quickly.

Another advantage of naming tests properly is when you are adding new tests. If you’re obliged to follow a descriptive tests naming convention, you need to think very well what your new code under tests should do and under what conditions. This makes your production code more structured and well-thought. Just give it a try, especially if you use TDD. I often start my TDD session with writing empty tests named correctly. This gives me many ideas of the production code I’m going to write straight after.

How naming tests well can help the business

I think I don’t need to explain that to you anymore. However, remember that your tests might be useful for other people than programmers. All non-technical people involved in the project can have a great use of the tests if you name them correctly.

I hope that your tests are executed as part of a CI process you use for your app deployment. As I wrote before, imagine having a late Friday release of your app. As a programmer, you’re the last one to commit this one last bug fix, and you go home. The project manager stays alone, waiting for the CI build to finish, so he can accept and deploy the new version of the app. But then, one of the tests fails. If your tests are named well, he will be able to easily judge whether this is blocking the deployment or not. I think that gives a lot of value to the business.

In case of some applications, where classes/services are created close to the domain of the app, business people can also explore the set of tests for a given service to grasp an idea of how it works and why it works as it does. Similarly, when you explore the tests class in your IDE. This wouldn’t be possible in every project, but it might also become a benefit of well-named tests in some cases.

Summary

I hope that after reading this article, you know why naming tests matters. Giving your test a descriptive name is a small effort, but it brings huge benefits. Both to your fellow programmers, but also to non-technical, so-called “business people”.

The post Why Naming Tests Matters? appeared first on Yumasoft.

Jest config

First, make sure that your jest configuration is correct. If you’re with TypeScript (and you should ?), I recommend using ts-jest configuration preset. Our config looks as follows:

If everything is fine, you should be able to execute npm test command (assuming it’s defined in package.json as "test": "jest") without issues. All your tests should be executed.

We now need to make StrykerJS working with that.

StrykerJS with jest configuration

If you install StrykerJS as described here, you’d expect that npx stryker run command runs mutations and everything is just fine. However, if you’re having wierd issues and errors with that, it probably means that Stryker is not properly configured to execute tests with jest.

When you run npx stryker run, it creates mutants (modifications in your source code) and runs tests against them. It means that StrykerJS must run your tests in the same way you run them. So, if you run tests with jest, Stryker must be able to do the same.

We struggled with many issues related to running StrykerJS with jest. Some of them were related purely to jest, but some of them to TypeScript as well. After numerous trial-and-errors and consulting with StrykerJS community members, we worked out a configuration that finally works fine for us.

Going straight to the point, here’s the stryker.conf.json file that would make StrykerJS work fine with jest and TypeScript:

To make it work, install the following npm packages: @stryker-mutator/core, @stryker-mutator/jest-runner and @stryker-mutator/typescript-checker.

Notice few important settings here:

• "checkers": ["typescript"] – this enabled a TypeScript checker plugin, which makes mutations being checked for types before running tests on them. It means that if a mutation introduced by Stryker doesn’t compile because of types issues, it won’t be taken into account for mutations (which makes perfect sense)
• “disableTypeChecks” – you still need to tell StrykerJS to not check types when compiling your code with type errors (mutants). It will compile them without types checking, but thanks to TypeScript checker plugin these ones will be filtered out for mutations
• "tsconfigFile": "tsconfig.json" – make sure to point to the TS config file you’re using here
• "concurrency": 4: this is another setting we experimented with to make Stryker working correctly. Without it, we were getting weird errors about lack of memory when running mutations (FATAL ERROR: Committing semi space failed. Allocation failed - JavaScript heap out of memory)
• "testRunner": "jest" – this one enables the jest as our tests runner
• "jest" – here you tell Stryker to use your jest.config.js file we talked about at the beginning

With these settings, I hope that you are able to see this beautiful output of npx stryker run in your console:

StrykerJS with jest and TypeScript – summary

I hope this is helpful for you. StrykerJS is a developing framework, so some things are still hard to figure out. We believe mutation tests are a great way of improving our tests, so we use them on a daily basis. If you ever have any issues with StrykerJS, I encourage you to reach out to the community on Slack. They are extremely helpful there ?

The post How To Use StrykerJS With jest And TypeScript appeared first on Yumasoft.