Tests: A Quick Overview on Unit vs Functional Testing

Here's a super quick peek into unit tests compared to functional tests. And full disclaimer here is that depending on your circle of influence, these might be given slightly different names. Try not to dwell on that but instead the comparison and contrast presented! Unit Tests Coded tests that take a white-box visibility approach to exercising and asserting that written code, generally a specific function/method, works as it was designed. Pros: Generally very programmer-focused Very granular coverage (breaks can identify exact lines where an issue occurs) (Should) run extremely quickly Have very little test setup in ideal cases Provide full control (generally via ‘mocking’ dependencies) to exercise very specific logical paths Cons: Generally more challenging to convey coverage to other stakeholders By nature these are brittle and break with refactoring Require sets of design patterns to help ensure tests are…

0 Comments

xUnit Tests Not Running With .NET Standard

Having worked with C# for quite some time now writing desktop applications, I've begun making the transition over to .NET standard. In my professional working experience, it was a much slower transition because of product requirements and time, but in my own personal development there's no reason why I couldn't get started with it. And call me crazy, but I enjoy writing coded tests for the things I make. My favourite testing framework for my C# development is xUnit, and naturally as I started writing some new code with .NET Standard I wanted to make sure I could get my tests to run. Here's an example of some C# code I wrote for my unit tests of a simple LRU cache class I was playing around with: [ExcludeFromCodeCoverage] public sealed class LruCachetests { [Fact] public void Constructor_CapacityTooSmall_ThrowsArgumentException() { Assert.Throws<ArgumentException>(() =>…

0 Comments

Refactoring For Interfaces: An Adventure From The Trenches

Refactoring: Some Background If you're a seasoned programmer you know all about refactoring. If you're relatively new to programming, you probably have heard of refactoring but don't have that much experience actually doing it. After all, it's easier to just rewrite things from scratch instead of trying to make a huge design change part way through, right? In any mature software project, it's often the case where you'll get to a point where your code base in its current state cannot properly sustain large changes going forward. It's not really anyone's fault--it's totally natural. It's impossible to plan absolutely everything that comes up, so it's probable that at some point at least part of your software project will face refactoring. In my real life example, I was tasked with refactoring a software project that has a single owner. I'm close…

1 Comment

End of content

No more pages to load