My first NuGet package! Kritner.SolarEstimate

I published my first NuGet package (https://www.nuget.org/packages/Kritner.SolarProjection/)!  Kristen and I recently were considering (and have since financed) a 17,000 kw/year solar array, on the back of our house - https://photos.app.goo.gl/gZzp7DnkeEcg1zQMA.  In the process of deciding whether or not to go for it, I started on some spreadsheets, to try and figure out when it would seemingly be "less expensive to have the solar panels, than our normal energy bill".

With that spreadsheet I thought that it seemed like a good opportunity to try out a few new things I hadn't - additional docker work, a NuGet package, some basic angular, typescript, more unit testing.  So over the past few weeks after dinner, I've been tinkering around with my website and produced solar-projection.  It started out all contained within my github repo of https://github.com/Kritner/KritnerWebsite, but I needed to figure out how to start playing around with NuGet, so now I have the core "solar projection" logic in its own package - its repo is located at https://github.com/Kritner/Kritner.SolarProjection.

The site is not currently pretty, but it does (hopefully accurately) tell me the information I wanted to know - solar panels seem to work out great for us, as long as we can get 90-100% power generation from the panels (and they're guaranteed for 90% of the 17k).

I hope to be able to continue exploring angular, to make it a bit prettier with perhaps some charting, and datagridding, and perhaps turn it into a stupid little app I could maybe make a few cents off of?  Currently the site only estimates ***my*** solar panel array, but it should be a quick change to allow some user inputs so others could use it too.

Oh! and if anyone's interested, the package could be used to run the numbers before I get the user inputs in (or you could do it for me? :D).  The solar array was installed via Vivint Solar, if you're interested in getting a system, I get referral bonuses, get at me!

Looking for recommendations - .net core compatible dependency mapping

I'm going to be looking into converting a lot of our projects into NuGet packages, and it is a large solution, so ideally I'd be able to map the current (pre NuGet conversion) project dependencies.

I'll be doing some research into potential extensions I can add to visual studio to do this, but if anyone has something in mind, suggestions are appreciated!

Something like this, but on a much larger project scale:

Update on keto

Hey, it's been like a month and a half since starting keto.  I'm down to 170, down to 20% body fat (depending on the day), and I haven't measured my belly yet, but two notches tighter on the belt.  Holy heckin gosh!

This is my first post since I was introduced to dev.to (I imported... most? of my previous blog posts).  This seems like a pretty cool platform, hopefully I'll be able to make more time for blogging (I think this is like the 5th time I've said this)

Started keto

Started keto with Kristen yesterday. Let's see how this goes!

I think I'll miss noodles most of all, but these fat bombs are hella good.

Started 71.5 inches, 185 pounds, 22.5% body fat according to my scale.

"non string" category NUnit tests

Didn't feel very "clean" about [Category("MyCategory")] peppered throughout the code base.  This makes me feel a little better, though I wish I could easily apply the category attribute to an entire assembly.

"Productivity power tools" allowed for the pretty paste from visual studio

    // Haven't figured out how to apply to assembly correctly, but added it as a flag in my base anyway
    [AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class | AttributeTargets.Method)]
    public class BaseCategoryAttribute : CategoryAttribute { }
 
    public class FastIntegrationTestAttribute : BaseCategoryAttribute { }
    public class LongRunningIntegrationTestAttribute : BaseCategoryAttribute { }
    public class UnitTestAttribute : BaseCategoryAttribute { }
    public class CoreTestAttribute : BaseCategoryAttribute { }
 
    [TestFixture, UnitTest, CoreTest]
    public class SomeClassTests
    {
        // This test has categories TestFixture, UnitTest, CoreTest
        [Test, CoreTest]
        public void ShouldDoSomething()
        {
        }
    }

xml2rfc oh my jeez

Ugh.  Been having crazy trouble with getting started with Python for windows, all the way through getting xml2rfc installed.  Background is I'm trying to regenerate some RFC documents based on JSON edits in the appropriate XML files for a project.

SO, here's the steps I (think) were taken in the end to get it working - in case I ever need to do it again.

1. Install Python 3.5 
1. URL 
1. https://www.python.org/downloads/release/python-352/
2. Exact link I used:
1. https://www.python.org/ftp/python/3.5.2/python-3.5.2-amd64-webinstall.exe
2. (Fails) pip install xml2rfc
1. Error related to lxml, for some reason exception being thrown from a VS14 directory?
3. (Fails) pip install lxml
1. Ok... so here's what not to do I guess
4. pip install wheel
1. After trolling through threads, found that "wheel" can be used to install lxml
5. python -m pip install lxml-3.6.4-cp35-cp35m-win_amd64.whl
1. From http://stackoverflow.com/a/30494745/2312877
2. Grab .whl for lxml (not sure why pip install lxml does not work)
3. Put in a directory
4. run command from base
6. pip install xml2rfc

Hooray!  That took forever... apparently stuff just needs to be done in a weird order, and not one that (at least I would) expect.  Oh how I miss npm compared to this package manager...

What is the Business Value of Unit Testing? Part 2

Part 2 you are here
Part 1

In the previous post, we started on a business application with the requirement:

> As a user, I need a way to enter a number. Once the number has been entered, I need it to be printed back to me.

The customer loves the app!  But has a few new requirements for us:

> As a user, I need a way to enter a number. Once the number has been entered, I need it to be printed back to me.
> If a number evenly divisible by 3 is entered, the user should receive back "Fizz" rather than the number
> If a number evenly divisible by 5 is entered, the user should receive back "Buzz" rather than the number

The requirements now are equivalent to the children's problem and/or code kata FizzBuzz

Our code previously only had a single branch of logic.  Get number, return number.  Based on the new requirements, we can see there will be a few more branches:

1. number is not evenly divisible by 3 or 5
2. number is evenly divisible by 3
3. number is evenly divisible by 5
4. (not explicitly stated but) number is evenly divisible by both 3 and 5.

The 4th branch was not stated by the requirements, but seem like something that should be asked of the business owner, as it might not have been considered, or could have even been assumed.

Our original method which looked like:

public string ReturnNumberAsString(int numberToReturn)
{
    return numberToReturn.ToString();
}

Will be updated to now look like:

        public string ReturnNumberAsString(int numberToReturn)
        {
            if (numberToReturn % 3 == 1 && numberToReturn % 5 == 1)
                return "FizzBuzz";
            else if (numberToReturn % 3 == 1)
                return "Fizz";
            else if (numberToReturn % 5 == 1)
                return "Buzz";
 
            return numberToReturn.ToString();
        }

Now be aware, all of our unit tests from last round, continue to pass, as the data that was being used to test the method continues to pass with our new implementation.  This is often something that is brought up as a potential pitfall of unit testing and requirements changing - and it is seemingly a valid concern!  Our unit tests are continuing to pass, when the requirements are much more complex than they were previously.

This is why it's so important to take into account *both* unit tests (and their asserts) as well as code coverage.  There is always the possibility that the unit tests *won't* break as a result of new branches in your code. BUT, if you were to look at code coverage, specifically the code coverage as it applies to our method, you'll see that not all branches of code are covered by unit tests.

As you can see from the above screenshot, our code coverage as indicated by the percent, and the purple and yellowish text has gone down.   The 3 new branches within our code is not currently being covered by unit tests.  Here's the repo as of updating the method, but without the unit tests to cover the requirements: https://github.com/Kritner/UnitTestingBusinessValue/tree/bb1f9bda9250fbdb85a8737c0c006f06e6daa788

Now to write a few unit tests:

/// <summary>
        /// number mod 3 and 5 returns FizzBuzz
        /// number mod 3 returns Fizz
        /// number mod 5 returns Buzz
        /// </summary>
        [TestMethod]
        public void NumberReturner_ReturnNumberAsString_SpecialCasesReturnValid()
        {
            // Arrange
            NumberReturner rt = new NumberReturner();
            int modThree = 9;
            int modFive = 10;
            int modThreeAndFive = 15;
 
            // Act
            var resultsModThree = rt.ReturnNumberAsString(modThree);
            var resultsModFive = rt.ReturnNumberAsString(modFive);
            var resultsModThreeAndFIve = rt.ReturnNumberAsString(modThreeAndFive);
 
            // Assert
            Assert.AreEqual("Fizz", resultsModThree, nameof(resultsModThree));
            Assert.AreEqual("Buzz", resultsModFive, nameof(resultsModFive));
            Assert.AreEqual("FizzBuzz", resultsModThreeAndFIve, nameof(resultsModThreeAndFIve));
        }

Hmm. We currently have a failing test.  Fizz is not being returned from resultsModThree, but 9 instead.  Let's see what's going on here.

Oh. Looks like I've inadvertently created a bug in my implementation of requirement #2.

if (numberToReturn % 3 == 1 && numberToReturn % 5 == 1)
    return "FizzBuzz";
else if (numberToReturn % 3 == 1)
    return "Fizz";
else if (numberToReturn % 5 == 1)
    return "Buzz";

Should have been:

if (numberToReturn % 3 == 0 && numberToReturn % 5 == 0)
    return "FizzBuzz";
else if (numberToReturn % 3 == 0)
    return "Fizz";
else if (numberToReturn % 5 == 0)
    return "Buzz";

Now that we've corrected the code, our new unit test passes. But our original unit test:

// Arrange
int expected = 42;
NumberReturner biz = new NumberReturner();
 
// Act
var results = biz.ReturnNumberAsString(expected);
 
// Assert
Assert.AreEqual(expected.ToString(), results);

Is now failing. Of course it is - 42 % 3 is 0, so we actually received a Fizz for 42. Updating that test to have an expected value of 7 instead.

What does all of this mean? Our unit tests both helped us and hurt us in this scenario.  They helped us because they helped us determine I had a logic error in my implementation of a requirement.  They hurt us because we had a "false positive" pass.  This is why it's so important that unit test Asserts are relevant, and code coverage stays high.  Without a combination of both of these, the business value of the tests is less significant.  The updated implementation and logic:  https://github.com/Kritner/UnitTestingBusinessValue/tree/78f03b8550593b9576f28e8608561f4add989879

In a non unit testing scenario, it is likely that our business logic would only be testable through the UI.  UI testing is much clunkier, slower, and harder to reproduce consistently.  Imagine after each change of our logic, we had to test all branches over and over again through the UI.  This probably means a compile, a launch, an application log in, navigate to your logic to test, etc.  Oh, and then do it three more times (due to this **simple** application's logic).  This is another reason unit testing is so powerful.  As we keep making changes to our code, we can help ensure the changes we're making are not impacting the system in ways we're not expecting.  And we're doing it in a fraction of the time that it would take to do the same thing through manual UI testing.

Hopefully this post and the previous help show how a good unit testing suite can really help you not only have less bugs in code, but get your code tested much faster.