CreepingCoder.com

Generate code coverage for .NET Core projects

Sun, 21 Jun 2020 00:00:00 +0300

What is code coverage?

In computer science, test coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. A program with high test coverage, measured as a percentage, has had more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low test coverage.[1][2] Many different metrics can be used to calculate test coverage; some of the most basic are the percentage of program subroutines and the percentage of program statements called during execution of the test suite.

Source: Wikipedia

Should I care about code coverage?

Code coverage is a metric and as such it can be used or abused.

I’ve worked on projects where we’ve had 100% code coverage and I’ve worked on projects where we’ve had close to 0% code coverage. I prefer working on a codebase with a higher code coverage, it gives you more confidence that you won’t break everything with a “simple” change. Of course, the code coverage percentage and the confidence though correlated are not linearly correlated! Having a 100% code coverage doesn’t mean you can’t break something, it just provides you with a higher confidence you won’t do so.

Having 100% code coverage

As mentioned, this is just a metric and not having end-to-end tests won’t save you from production failures. Okay then, but then should I strive for 100% code coverage? The answer is - it depends. ;)

It depends on your team, it depends on the product you’re building, it depends when you want to ship it, etc. Not all code coverage is the same, having 50% code coverage for non-critical features is less valuable than having 50% but having all your critical sections covered.

Legacy projects

When working on legacy projects with a low code coverage - your goal should be to increase the code coverage (or at least not to decrease it!). It’s not realistic to go from 20% to 100% overnight. Reaching 100% on a relatively big project is a big effort and would definitely require change of the project priorities.

I have 2 simple rules which I try to follow when working on such projects:

Add a test for any newly written code.
Add a test when you change “old” code.

Don’t be mistaken, simple doesn’t mean easy. Not having tests probably means it’s not really straight-forward adding such, because if it were that easy - probably somebody else would have probably already done it. It’s important to take time and add such tests if you consider this part of the code critical, if not - then you could probably skip it, but be ready to go back and fix it again. :)

New projects

Everybody loves new projects. Starting a new project fills you enthusiasm and we’re thinking “i am going to do it right this time!”. More often than not - we’re doing the same mistakes over and over again. It’s important to lay the right foundations (and restrictions) from the beginning. Having strict rules is great when you don’t have to worry of 5-years worth of code!

You can configure the linter exactly how you won’t and you won’t rewrite the history of practically every file under source control (or do stupid git hacks to workaround it).

You can have a hard-rule for the code coverage and while you are it - just have it at 100%! But why should it be 100% and not 95%, but what about 90% or 75%? You get the point, having the choice will always start discussions. It’s black/white rules. Having the code coverage at 100% - doesn’t mean you need to have a 100% code coverage, but it means by default you should cover your newly written code, if a new piece of code can’t be instrumented - then this would be the exception, not the rule! Note also, that having 100% code coverage doesn’t mean you’ve tested all the cases, it means all branches’ code has been executed, but you may have not actually asserted anything and everything can be wrapped in a try/catch block. This will fool the tooling, but that’s not what we want, right? :)

Having black/white rules is very useful for linting as well - just break the build if you have 1 or more warnings or errors - no discussions there! Yeah, have a discussion what constitutes an error for your project, but don’t start a flame war how many errors is OK to have.

The whole point of the tooling is to minimize the trivial comments in PRs, have the tools do the heavy-lifting, this way you enable the developers to focus on the really important parts of the code - not on technical details as why is this not properly indented, there are tabs instead of spaces, etc.

Unit tests and .NET Core

Running tests with dotnet CLI is really simple, but has a minor difference than using vstest console runner - you need to pass a project file and not an assembly! What this means you can’t tests from multiple assemblies with a single command. That’s a shame… Good we’ve MSBuild built into dotnet so we can hack our way around it! If you have missed the previous post - go check it out.

Running the tests

All you need to do is the following in the directory of the test project:

dotnet test

or if you are in the root solution dir

dotnet test <project_path>

Collecting code coverage

It’s as simple as adding --collect:"Code Coverage" to the dotnet test command!

Unfortunately, there are a couple of gotchas you need to consider.

Running on non-Windows OS

You need to run on Windows or you would get the following error:

Data collector 'Code Coverage' message: No code coverage data available. Code coverage is currently supported only on Windows..

That’s a downer, but it should be fixed sometime in the future. Check this GitHub issue if you want to track the progress of this.

In the meantime, you can use coverlet.collector. You add it as a reference to the test project and change the command collector type from Code Coverage to XPlat Code Coverage.

Here is the whole command, for example:

dotnet test Lib.Tests/Lib.Tests.csproj  --collect:"XPlat Code Coverage"

* Not sure if coverlet results file is supported by Azure DevOps or you need to convert it.

If you are building on Windows, just use the first command as it can generate the TRX files and the code coverage files which can be seamlessly published to the Azure DevOps. Probably there are plugins (maybe called tasks?) that can parse the Cobertura format, not sure. Why am I mentioning Azure DevOps - well, this was the CI provider I use, so I solved for my problem. :)

Updating the Microsoft.NET.Test.Sdk package

Make sure you are running the latest version of this package or you are likely to have issues. If you don’t have the package explicitly listed - add the latest version of it!

Running tests as part of CI

And we come to the final part. We’re going to leverage the knowledge from the previous post and this one to have a working MSBuild script executing the tests from all of our test projects. Generating code coverage as well and erroring out if we have any failing tests. I am just going to add the code as I think it’s pretty self-explanatory.

<ItemGroup>
  <DotNetCoreTestProjects Include="$(SolutionDirectory)\**\*tests.csproj" />
  <DotNetCoreTestArgs Include="--verbosity:normal" /> <!-- Default verbosity is "minimal" -->
  <DotNetCoreTestArgs Include="--no-build"/>          <!-- If you've already built the solution you can safely add this -->
  <DotNetCoreTestArgs Include="--logger:trx"/>        <!-- Add the TRX logger so we can publish the test reults -->
  <DotNetCoreTestArgs Include="--results-directory:&quot;$(TestResultsOutputDir)&quot;"/>
  <DotNetCoreTestArgs Include="--collect:&quot;Code Coverage&quot;"/>

  <UnitTestExecutionExitCodes />
</ItemGroup>

<Exec Command="dotnet test %(DotNetCoreTestProjects.FullPath) @(DotNetCoreTestArgs, ' ')"
      ContinueOnError="true">
   <Output TaskParameter="ExitCode" ItemName="UnitTestExecutionExitCodes"/>
</Exec>

<Error Text="Unit test execution failed!" Condition=" '%(UnitTestExecutionExitCodes.Identity)' != '0' "/>

The snippet above will execute the dotnet test command and all the defined arguments for each test project matching the **\*tests.csproj search pattern. No need to update the script if you add a new test project which name ends with Tests.csproj. That’s pretty sweet, we want to have script that we write once and don’t touch anymore. If you need to touch it every time you add a new project - chances are you are going to forget to do it and your tests won’t get executed! Having conventions for naming the test projects is useful in on itself, but not having the need to touch the script is a stronger reason.

I want to draw your attention to the ContinueOnError=true - that’s pretty important as mentioned before, we want to execute all tests and THEN fail (if there are failing ones). That’s important so you can see all failing tests on the first run! If you have failing tests in multiple projects, we’re going to get the errors one by one for each successive run and we don’t want that.

Closing thoughts

I’ve always been a proponent having my build scripts in the source control and not in the CI tool, be it TFS, Azure DevOps, Jenkins, TeamCity or whatever. Yeah, the tools have history as well (they didn’t before), but you are coupling branches and builds which is bad. Any change you need to make would require you to sync things in 2 places - source code and CI tool! Just move everything in a single place - the source control. You can have per-branch changes that won’t affect every other branch there is.

Of course - you can go with Azure Pipelines (YAML) for example - it’s per branch and is stored in source control as well, but you can’t really run the script locally. Yeah, probably there are some tools that will do that for you, but it’s another thing you need to think about and check if everything is really supported. MSBuild gives you the flexibility to experiment with the scripts locally (almost an instantaneous feedback loop), no need to wait for build agents, source retrieval, etc. You can easily comment-out unneeded steps to speed-up the feedback loop even more! And most importantly - you have environment-agnostic scripts - you can execute them locally or somewhere else, they should behave the same as MSBuild will be the same on all the environments. Yeah, MSBuild is not easy/fun to write, but it’s definitely better than YAML. YAML is not made to be written by humans, but to be automatically generated (prove me wrong).

I’ve been using this script for 3+ weeks now and I haven’t touched it! 3 weeks may not sound like much, but new test projects were added, old ones were moved and everything is still working as in the beginning, so I say this works well enough for my case! ;)

MSBuild 101: Using the exit codes from multiple commands

Sun, 14 Jun 2020 00:00:00 +0300

A continuation of the previous post. Today we’re going to take a look how we can execute multiple commands with MSBuild.

Hopefully, you took the time to familiarize yourself with the MSBuild concepts listed in the previous post, if not - go check it out.

Executing multiple external commands

Last time we wanted to execute a single command and check its error code, although useful, it’s kinda limited. Usually, we want to execute a set of commands instead of a single one.

The copy/paste way

Remember - your first job is to get the everything working, refactoring and optimization come after that!

Here is the simplest way to do it:

<Exec Command="echo foobar" />
<Exec Command="echo zaz" />

More of “MSBuild” way

Although we can define a single exec task, we can use it to iterate through a list of commands, like so:

<ItemGroup>
    <Commands Include="echo foobar;
                       echo zaz" />
</ItemGroup>

<Exec Command="%(Commands.Identity)" />

Now that’s more lines, however, we only need to touch the commands item group, no need to copy/paste the exec task!

Of course, you can get away when you know all your items (or commands), however that may not always be the case. Then you can’t go with the copy/paste way. :(

Check the exit codes

Now that we’ve executed multiple commands we may want to check their exit codes. In my previous post we checked the exit code of a single command. That’s pretty easy, we write it to a property, but we don’t have a single command now, we have multiple commands. That means a property won’t suffice.We can leverage an item group for this use case!

Here how this can be done:

<ItemGroup>
    <Commands Include="echo foobar;
                       echo zaz" />
</ItemGroup>

<Exec Command="%(Commands.Identity)"
      ContinueOnError="true">
    <Output TaskParameter="ExitCode" ItemName="ExitCodes"/>
</Exec>

<Message Text="ExitCodes: @(ExitCodes)" />

If you run the snippet above, you’re going to get the following output in the console:

foobar
zaz
ExitCodes: 0;0

* Do note the ContinueOnError attribute, if you omit this, only the first command will be executed in case of an error!

Rule of thumb

If you need more than 1 property - use an item group!

Bubble-up the error

If you want to bubble-up the error, you can add an Error task as follows:

<Error Text="Command execution failed!" Condition=" '%(ExitCodes.Identity)' != '0' "/>

This will go through every item (0;0) in the item group (remember, items printed with a semi-colon delimiter) and check if it’s different than 0, if it is - Command execution failed! error will be raised.

Final words

This is you can execute multiple commands and fail after each one of the commands is executed.

Next time we’re going to use the knowledge to actually do something useful!

MSBuild 101: Using the exit code from a command

Mon, 01 Jun 2020 00:00:00 +0300

MSBuild is a really interesting beast! He who has not used it haven’t encountered its quirks!

Should I care about MSBuild?

If you are working on a .NET stuff, you definitely should know how it works, because the whole .NET ecosystem is built around it. From your project files (e.g. csproj) all the way down to all Microsoft targets. Varying from what should go to the intermediate (obj) dir and what to the output (bin), copying references (if needed) or even publishing a self-contained executable (if using .NET Core).

Basically, there is not way around it! Love it or hate it - you are going to use it.

MSBuild 101

Before continuing, you should familiarize yourself with 2 core concepts:

Those are the 3 building blocks of MSBuild.

If you don’t want to dig in, just remember this:

Properties are used for a single value (e.g. path to a config file).
Items (or items groups) are used for multiple values (e.g. list of all project files).
Tasks do the actual work (executing commands, copying stuff, etc).

Execute an external command

Executing an external command in MSBuild is pretty easy, we need to just use the exec task like so:

<Exec Command="echo foobar" />

Pretty simple and of course - pretty useless!

Check the exit code

In a lot of scenarios you want to check the exit code:

<Exec Command="myecho foobar"
      ContinueOnError="true">
    <Output TaskParameter="ExitCode" PropertyName="MyEchoExitCode"/>
</Exec>

This will set the MyEchoExitCode property to 127 if running on MacOS and 9009 if running on Windows for command not found (unless you have myecho executable in your PATH).

Note the ContinueOnError part - if omitted the script will fail and the execution will stop. You can think of it as a try/catch block!

* You can check more options for the exec task.

Act accordingly

Having captured the exit code was the hard part! Now comes the easy part - doing stuff with the result you’ve got.

Having repeatable build process is a MUST, but you can spice it up with the following snippet:

<PropertyGroup>
    <IsBlueMoon Condition=" '$([System.DateTime]::Now.ToString(ss))' == '59' " >true</IsBlueMoon>
</PropertyGroup>

<Exec Command="build my.project"
      ContinueOnError="true">
    <Output TaskParameter="ExitCode" PropertyName="BuildExitCode"/>
</Exec>

<Error Message="BUILD FAILED!" Condition=" '$(BuildExitCode)' != '0' AND '$(IsBlueMoon)' != 'true' ">

This way your build won’t fail when there is a blue moon outside!

Final words

That was a basic example of how you can use MSBuild to execute a custom command and check the exit code.

Next time, we’re going to leverage this to actually do some useful stuff! ;)

Finding wrong reference hint paths in C#

Sun, 09 Feb 2020 00:00:00 +0200

I am back in the .NET world in the last couple of months. This is after almost 2 years break I took from C#. ;)

A lot has changed and yet, everything is the same! Yeah, yeah, I am not working with .NET Core, but still…

The project I am working on uses the legacy Reference, not the shiny new PackageReference (more info).

The good news is we plan to migrate to PackageReference usage, but things are not so simple. The main reason is you need to migrate all projects all at once, because VisualStudio doesn’t play well with mixed usage, which is expected after many years in the Microsoft eco-system.

The bad news is upgrading 70+ projects is not a trivial task. Having “zombie” references (not used by anyone) is not helping either.

Building a fresh repo was failing

Using assemblies from other project output directories

If you got a fresh repo copy and try to build the solution - it was failing. The reason for this was some references were pointing to the bin/Debug or bin/Release directories of other projects.

Of course, from experience, if something is messed-up on one place, most likely it’s not the only one. So, I I searched throughout all the project files:

<HintPath>((?!packages).)*<\/HintPath>

This is a regex search*, which finds all HintPath tags NOT containing packages string inside them.

* Make sure to enable regex search in VisualStudio. I use VS Code when manually editing project because there is no need to unload them.

Using .NET Standard references

Now, there were cases where .NET Standard references were used when there is a full framework alternative already built. For that I used the following pattern:

<HintPath>(.*)?(netstandard)(.*)?<\/HintPath>

Note that not everything containing netstandard should be changed, but there are cases where you want to use the full framework assembly, so you don’t pull all the .NET Standard dependencies in your output dir. This is a manual process if you don’t want to reinstall a given package. ;)

We had a couple of those, note that using a wrong assembly may generate a wrong binding redirect build time (the so called - unifying), which can “magically” break your application on testing/production environments. I don’t know why this is enabled by default, but it’s something to keep on the back of your mind.

Conclusion

For now, we’ve fixed our immediate issues. It’s time consuming as each time you install a new package, you have 3 files you need to take care of:

project file
packages.config
app.config or web.config

Of course, there are issues with the so called binding redirect, Microsoft messed up their versioning on some of the assemblies which generates a lot of manual work every time you use NuGet through the VisualStudio interface. :(

This becomes pain in the butt when you have 70+ projects and a lot of people working, because usually you touch a lot of files when you fix any issues package/reference issues.

Good thing is NuGet is now fully integrated in VisualStudio 2017 or later. I remember using NuGet way back in the day was painful and they alleviated some of the pain, but .NET hasn’t really solved the issue with different package versions. You can check this very interesting blog post by Jon Skeet. I believe this causes a lot of weird behavior described above.

Maybe I can write something about using PackageReferences and binding redirects in another post. There is a lot to share there as well. Stay tuned! :)

Fixing random color changes on Catalina

Sun, 08 Dec 2019 00:00:00 +0200

After I’ve upgraded to MacOS Catalina I started experiencing really weird color changes.

For example, I am working in the afternoon (2PM) and my colors get “yellowish” and after 5 seconds it goes to its normal colors. Of course, my first though was, hey (f.lux)[https://justgetflux.com/] is playing tricks on me, but I was wrong.

The problem

It seems with Catalina, Apple introduced the so called (True Tone)[https://support.apple.com/en-us/HT208909]. How this feature works you may ask? Well, from my understanding it reads a sensor located in the front camera and checks if it’s day or night. If it’s night it uses warmer colors (this should make you fall asleep easier, you know). However, this doesn’t work well if the sun is blocked by a cloud, because the color change is triggered.

The solution

Well, just disable the True Tone as it’s described in the article above.

Why use f.lux?

As I mentioned, it’s supposed to help you fall asleep easier. Personally, I don’t have hard time doing so and I am not sure if that’s because of f.lux, but generally it seems like a good idea not to use bright screen late in the evening.

Also, I am wearing glasses that have some kind of a blue filter, which is readily visible when reading my Kindle.

I use the recommended settings of f.lux, which means when the sun is set all the colors are warmer. I’ve enabled the OS X dark theme at sunset, which is kinda nice indicator for the end of the work day. :)

Using nvm and nodenv side-by-side

Sat, 05 Oct 2019 00:00:00 +0300

If you’ve read my last post, you know that I’ve switched to using nodenv from nvm.

Why?

I don’t want to explain again, so you can read more about it.

The problem

Running the project with different versions of NodeJS may lead to unexpected results. This is especially true if we are talking about projects where more than 1 person is working on. But it holds true for personal projects that have been on the back-burner for some time.

Don’t forget this timeless quote:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

Source from StackOverflow.

Speaking from my personal experience, 99% of the time, the person knows where you live! Because this person is you! Yep, the person who wrote this “ugly piece of shit” was old me!

So… make sure you’ve done the best to your abilities to soothe the next person who’s gonna work on it. :)

The solution

If nvm is already adopted on your team - great! It’s a step in the right direction, also, good amount of CI providers have support for it (e.g. Bitrise).

Add an .nvmrc file with the following content: 10.16.3 (this is current LTS version, but probably won’t be by the time you read this).

Now, you want to have a .node-version file with the same content. But although copy/paste is the best tool in a developers toolbox, it’s not the right tool for our job.

You want to symlink .node-version to .nvmrc, in order to do so, execute the following command in the root directory of your repo:

ln -s .nvmrc .node-version

Now, if you execute ls -la then you should something like that:

❯ ls -l .node-version
lrwxr-xr-x  1 steliyan  staff  6 Oct  5 19:02 .node-version -> .nvmrc

You’ve successfully symlinked .node-version to point to .nvmrc!

Conclusion

Don’t rely on the aliases that nvm supports!

Updating this file takes a minute! Testing those changes will take more time, but that’s to be expected! It may just mean to run all the integration tests locally or on your CI server. In the long term - this will save your time, and probably your ass!

The builds or environments are not reproducible. It may be OK for an evening project (but don’t forget about the psychopath who knows where you live!), but for production environment it’s absolutely not recommended! Something is going to fail when a trivial fix is being deployed. You can pray that to be the build, because more subtle errors may creep into production! However, having a broken build when you want to deploy a business-critical fix/feature is no fun.

Try answering this one question - would you produce a production build of your app without using a yarn.lock or a package.lock file? Yep, I thought so. :)

I’ve personally had a similar issue with this blog. I may write a follow-up post on that some day! ;)

Start using Prezto!

Sat, 28 Sep 2019 00:00:00 +0300

I was using oh-my-zsh for a really long time and I was pretty happy with it. However, lately I decided to look for an alternative, more specfically - a more performant one. And I stumbled upon Prezto.

Getting rid of oh-my-zsh

As I mentioned, I was using oh-my-zsh, first thing we need to do is to get rid of it! This can be done pretty easily, you just execute the following shell script:

uninstall_oh_my_zsh

This will perform the uninstallation and will create backup of your current .zshrc file in the home (~) directory, the new file will be something like: ~/.zshrc.omz-uninstalled-2019-09-22_08-31-19.

Installing Prezto

This is pretty easy, you can follow the instructions in the GitHub repo.

If you’ve done everything correctly, you should have your Prezto installed in ~/.preztorc directory.

How to “extend” PATH?

You can add your custom directories to PATH by editing the zprofile file. Here is an example from the current latest source.

Enabling “vi” mode

If you a fan of vi, you can enable this mode for your shell. If you haven’t tried it before - I think you should… I am struggling myself to learn some of the most basic vi usage (may have another blog post on that).

Edit the following line, change emacs to vi.

Clipboard

If you want to have your vi clipboard to work with the system one, you need a plugin. contrib-clipboard is the one that I use. Again, follow the instructions. After that, you need to list the contrib-clipboard in zpreztorc.

Slow input

Add KEYTIMEOUT=1 to your ~/.zshrc to eliminate the ESC delay.

Changing your theme

Just take a look at the author’s instructions. Personally, I use powerlevel10k, it has a nice wizard, where you choose the whatever looks best to you! Also, it auto-installs the needed fonts!

Set your NodeJS environment

Add nodenv

Don’t use NVM. It’s sooo slow, one of the reasons I started looking for an alternative to oh-my-zsh. A quick FAQ why you should choose nodenv. It’s worth the time (2min read, probably).

It works instantaneously, something which can’t be said for NVM. Just search for “nvm slow” and you’ll know what I am talking about.

Installation

You should use homebrew if you are using MacOS. Just execute the following:

brew install nodenv

Please note that there is a single e in nodenv, this tripped me while setting up my shell. There is a nodeenv formulae as well…

Of course, if you are a developer, you know copy/paste is always the way to go. ;)

More detailed instructions you can find in the GitHub repo.

Setting up Prezto

Add the following line: eval "$(nodenv init -)" in your ~/.zshrc after sourcing Prezto.

But it doesn’t work with .nvmrc

Yeah, that’s the drawback. There is a nodenv-nvmrc fork that does just that. I don’t recommend it though. Auto-changing versions between builds is not something I want, especially in a production environment.

Just lock down your NodeJS version using a .node-version file!

Conclusion

After a week, I am really happy with my new setup. I forced myself to learn something new and now I am struggling every day in the terminal, because I am using vi mode. Also, this post was written entirely in vi, took a little bit longer than anticipated, but hey, I may start to love it. ;)

Other resource

Make sure to check these awesome blog posts:

Absolute imports in create-react-app

Sun, 22 Sep 2019 00:00:00 +0300

Don’t you hate when you need to import a module, but you need to import 2 directories up? Or was it 3?!

I think everyone’s felt the pain if he has written any React code. :)

What is a relative import?

Here is a sample code which imports a Redux action creator:

import { removeUser } from "../../../actions/removeUser";

This hurts the most when you move a component or create a new one which needs to import something which is waaay up in the project’s structure…

What is an absolute import?

Now that we’ve seen what’s a relative import, we can show what’s an absolute import.

Here it is:

import { removeUser } from "actions/removeUser";

Way better, huh?

I don’t know about you, but I really don’t want to specify all the ../../.. paths. Also, it’s ugly!

Okay, but how?

Well, it documented in the create-react-app docs, which are pretty good actually!

You need to create a jsconfig.json file at the root of your project, NOT the src directory, with the following content:

{
  "compilerOptions": {
    "baseUrl": "src"
  },
  "include": ["src"],
  "exclude": ["node_modules"]
}

I’ve added the exclusion of node_modules. Not sure why was this needed, but I experienced some issues when it was not present. Maybe I’ll write a follow-up post later on that topic some day.

Is that all?

Well, this works great if everything you need to import is located under src/ directory, but what if I have a tests directory with all the test helper functions you need, which is at the same level with the src directory? Well, you’re out of luck… :(

Or at least you were! Now (some 9-10 months ago…) the following pull request was merged! The most notable thing added is the support to override moduleNameMapper for jest!

What this means is we can map our tests modules the way we want! Here is what I do in my package.json:

"jest": {
  "moduleNameMapper": {
    "tests/(.*)": "<rootDir>/tests/$1"
  }
}

Now if we import tests/constants in our tests we’re going to get the proper modules resolved, no need to specify a relative path anymore!

But VS Code can’t navigate to my JSX components?!

Well… yeah. There is an issue, you just need to add the following line under compilerOptions:

"jsx": "react"

NOTE: This was taken from the following response.

Final result

Here is the final result, ready for copy/paste, in all its glory:

{
  "compilerOptions": {
    "baseUrl": "src",
    "jsx": "react"
  },
  "include": ["src"],
  "exclude": ["node_modules"]
}

Conclusion

That’s it! I find this very useful and I am pretty sure it boosts my productivity.

Writing the absolute imports may give you an insight if you’ve structured your project badly as well!

Until next time! ;)

What is an "incoming change" in VS Code?

Sat, 21 Sep 2019 00:00:00 +0300

This is a post mostly for myself. Einstein said that you truly understand something if you can describe it to a 7-years old.

So, this is my attempt to explain something to myself in a blog post. :))

The “problem”?

Here’s what I often wonder is which is the incoming and which is the current change. Of course, you are thinking it’s very obvious then you’re probably right. But hey, some of us are not that quick thinking… apparently. ;)

My development workflow

Create a feature branch from master.
Add some stuff there.
Rebase feature on top of master.
Open a pull (merge) request.

When the lighting strikes

If there are no conflicts between feature and master step 3 “just happens”. However, if there are, you see the following dialog in VS Code:

I’ve annotated what is coming from master and what is from the feature branch. To understand why the current change is from master should be obvious if you know how rebase works in git.

How does rebase work?

rebase gets the branch name you’ve given and then replays all of your commits on top of them. In our case, this means master is the current and while every change that is applied is an incoming one.

Conclusion

That’s it! Now I’ve explained this to myself, hopefully I won’t be thinking this every time I need to resolve a conflict in VS Code.

Please note, if you are using merge to integrate master to your feature branch the “roles” are reversed! But hey, don’t do that, make the reviewers’ life easier! ;)

What is "describe" useful for?

Mon, 12 Aug 2019 00:00:00 +0300

I thought I knew what describe was for. But as almost everything under-used, I didn’t really knew what I could REALLY do with it. ;)

It proved itself more useful than I thought. Besides grouping of tests - the thing I’ve used it before (which can be really cool and useful, too!), it has one great use-case - it gives you the ability to run beforeAll/afterAll (or beforeEach/afterEach) setup “hooks” (too much React Hooks?!) per describe function.

This is really helpful when you have a more complex test scenarios. Like setting up some mocks to validate the success and the error paths. You can setup the appropriate mock depending on what you want to test.

Here is a quick code sample:

afterAll(() => {
  // restore the default mock after all tests
  setupMock();
});

describe("success", () => {
  beforeAll(() => {
    setupMock({ status: "OK" });
  });

  it("should succeed of course ;)", () => {
    // write your magical code here!
  });
});

describe("error", () => {
  beforeAll(() => {
    setupMock({ status: "ERROR" });
  });

  it("expect only errors here... :(", () => {
    // the "bad" code goes here...
  });
});

I’m not suggesting this is the only valid use-case of describe, but it was something I actually needed in my job. ;)

Think twice before using those “hooks” (beforeAll, afterAll), they can be easily overused.