In May of this year, I wrote an article on how to get JetBrains Rider to generate SpecFlow files. The biggest problem I still had back then was that I couldn’t generate the step definitions. I finally found a workaround so I don’t need to use Visual Studio anymore.
In the newer services at my client, AutoMapper is used to map DTO‘s to database objects and back. Because mocking a mapping isn’t obvious, a lot of behaviour wasn’t tested and that’s unacceptable. Let’s find out how to properly inject an
IMapper with actual mappings.
To create a report, I had to combine the contents of several PDFs into one. Thanks to iTextSharp, it’s really easy. Then I had the problem, how do I test this?
While writing an XML parser I customised, my unit tests all failed with an error message along the lines of “Could not load file ‘C:\Users[username]\AppData\Local\Temp[guid]\Data\test.xml’ or one of its dependencies. The system cannot find the file specified.”.
While I worked at my previous employer, I build a proof of concept to improve their ability to search. I will rebuild that proof of concept and I’ll highlight all the patterns and principles I used to build this code. All code related to this proof of concept can be found in a repository on my Github account.
In this fifth and last part, I’ll talk about additional benefits that this implementation can use.
In my current job, I’ve heard dismissive talk about testing. Along the lines of “well, that’s cute that you did that, now get back to work”. Work being manual tests to make sure everything works as intended.
Recently I went to a session given by Maarten Balliauw about memory management. In that talk, he mentioned the effect boxing and unboxing has on performance. He also talked about how a lot of strings can affect memory management. This got me thinking on the impact of boxing and unboxing when I format strings. What kind of impact does it have?
A while ago, colleagues and I encountered strange behaviour on our Continuous Integration server: several tests were run twice.
The problem was caused by a test project that was referenced in another test project because of some infrastructure code that was reused. Probably a Visual Studio or ReSharper suggestion of “Would you like to reference ClassX from Project.Y” and somebody just clicked “accept” or maybe even ReSharpers auto resolve all references of pasted code. This caused a test assembly to be loaded twice and thus the tests were discovered twice. Assemblies should not be carelessly referenced.
We solved it by putting all general purpose infrastructure code into a separate assembly that can be safely referenced throughout all the test projects. Case closed.