Getting started with unit testing within the confines of an existing monolithic vb.net application is a very tricky thing to do. I always want to do the right thing, but sometimes the code makes the unit test biased, or a lot of the functionality that needs testing is nestled away within private functions.
What do i currently do in such cases? Currently I leave the code as it is. The monolith is definitely resembles the structure in 2001 : A space odyssey. The Application sucks in all around it. It’s references and call hierarchy mean it can suck up days of life trying to figure out what calls it and what it does.
Sometimes the code is small and forgiving, (and importantly, public) meaning that I can write some small tests for it. But the tests always feel biased, like I already know how to pass them, which makes them feel dirty.
Usually I only write tests for new, greenfield, code. And I try and follow some of the courses I’ve seen on Pluralsight and Youtube. But I can never work out what is the correct/most efficient way to do it. This website is going to help me do this. I’m going to endeavour to write TDD code in my own way (using clean architecture), and utilise said tutorials to guide rather than have them be a set-in-stone methodology.
Leave a Reply