The Microsoft unit testing code for managed code allows to create test methods that are executed with data automatically fetched from an external data source. This is very helpful because we can extend the data sets without modifying the test code. An external data source can be an SQL database, a CSV file or Excel document, an XML document, or anything else for which a provider for .NET exists. In this article, I will show how you can define test data using all these types of source and execute unit testing methods with it.
Some time ago I published a Visual Studio extension called Memeful Comments for displaying images, including animated GIFs, alongside your code to enhance explanations with visuals or simply to express your reaction to the code. This extension is now available for Visual Studio 2019!
Visual Studio 2017 has had a larger number of updates throughout its lifetime. At the time of writing this article, there have been ten major updates and countless minor ones. You can check the release notes history for details. Part of the changes was in the debugger. In this article, I will mention three features…
The first preview version of Visual Studio 2019 is available since the beginning of December 2018. I decided to take a look to see what is different from the previous Visual Studio 2017 version. In this post, I will present some of the things that are new or changed in this new version.
I recently migrated an old VC++ project to use the Visual Studio 2017 toolset and when compiling I run into the following errors about redefining the structure tagTOUCHINPUT.
Although this feature is available for years in Visual Studio, I only recently discovered this gem that allows rapid generation of C# classes from either JSON or XML.
Here is how it works:
- Copy the JSON or XML code to the clipboard.
- In Visual Studio, go to Edit > Past Special and chose either Paste JSON as classes or Paste XML as classes.
Unit testing is usually used for testing public types and members. However, there are cases when you might need to test types or members that are not public. These could be internal classes or private helper methods, for instance. Whether that is proper unit testing or beyond its scope is not a discussion that I want to get into here. However, in this post, I will show how you can unit test non-public types and members from .NET assemblies.
When faced with the need for testing non-public types and members you can use several approaches:
- change the accessibility to public; you can do that perhaps only for debug builds and keep the intended accessibility in release builds by using conditional compilation.
- provide public members of a class that invoke private ones;
- use reflection.
The first solutions involve changing the API only for the sake of the testing. The last solution avoids that but requires more work. To help with that, the Visual Studio unit testing framework provides some helper types that enable you to focus on the actual testing and be less concerned about the reflection details.
I recently installed a fresh copy of Visual Studio 2017 on a new machine and went on to build several projects some of them being VC++. The trouble was that I immediately run into a problem (actually the first problem was that MFC & ATL were missing because I forgot to check that in the list of Individual components so I had to install them separately). The problem was an error with a missing new.h header:
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\atlmfc\include\afx.h(62): fatal error C1083: Cannot open include file: 'new.h': No such file or directory
A couple of weeks ago, version 15.8 of Visual Studio 2017 was finally released. You can read here about the new things available in this version. In this post, I will discuss five productivity features available for C++ development.
In my previous article, C++17 removed and deprecated features, I presented a list of the most important features that were either removed or deprecated in C++17. When you’re using deprecated features, compilers warn you about that. In this article, I will show how you can silence these warnings when using Visual Studio 2017.