The installation of SonarQube is well documented and easy to follow. However, SQL Server Express brings its own challenges. There are some configuration changes you must make or SonarQube will not work. This installation walkthrough will address those issues and help you to overcome them.
The "Given, When, Then" syntax of behaviour-driven development (short BDD) is a great way to get the business involved in the software development process. SpecFlow allows you to use this kind of example based specification with your .Net projects. Unfortunately, there are two obstacles that make the installation of SpecFlow and its commercial extension SpecFlow+ a challenge. This post will guide you through the installation process and help you to overcome those obstacles.
A common requirement for applications is to display a list – that can range from products to search results. While showing all entries works for small lists, it is not that useful for lists with hundreds of entries. In this case you should use paging and only show 10 or 20 entries at a time. The user sees the first part of entries and then can switch to the next page of the list to get more entries. This approach is faster, reduces the workload on your systems and the user isn’t drowning in data. Let’s look how you can implement paging in applications that use SQL Server.
A common task for developers is to store application specific configuration. There are many ways you can take to get that functionality. If you use .Net / C# you can use the simple, built-in way to work with configuration files. Let’s look how this works.
We started the migration to NUnit 3.0 as soon as the final version was released. Unfortunately, some bugs on Visual Studio Team Services ended this endeavour rather suddenly. We concentrated on shipping our product and postponed the upgrade. Now, with all our projects migrated, it is time to look back on the breaking changes that took the most time to upgrade.
Certain questions about a project can only be found in the source repository. The commit messages contain details on how your code was developed that you probably nowhere else have documented. The same is true if you want to know how many commits where made in a branch.
If you ever debugged code that had a list, you wished you could see more than the namespace and class name for the elements in that list. Today we look at one of my favourite features of OzCode to solve exactly that problem.
A good testing strategy may reduce your bugs tremendously. However, some bugs may still slip through and can only be found on your production environment. Today we look at a great feature of OzCode to isolate problematic data to use it in regression tests.
Good test data is as realistic as possible but isn’t from production. Leaks can happen on test systems as well and they are often less protected as production systems. Whenever you need test data you can start creating it from scratch or write a tool. Both options take time and effort. However, there is a third option: test data generators. Today we look how you can create realistic test data without much effort.
The .gitignore file is a great help to ignore certain types of files (like *.exe or *.dll). A little entry in this file and you no longer need to remember only to check in the files you really need but not the other ones.