GetNoticed DEV#3: Going in circles is not always a bad thing

Nau mai!
I am a bit stuck. I have this feeling that I am going in circles. But I wouldn’t say in this case that it is actually a really bad thing. It’s more like going in circles but with each circle its radius is growing so the perimeter is also growing.
What I mean in that a bit literary sentence above? It means that in terms of functionality, efficiency or feature-wise (or whatever it’s supposed to be called) I didn’t achieve anything new. As it was mentioned in my previous dev post I have restarted the project. At this point I have rewritten everything I had before the restart. Only better. Still far from perfection as I am trying to take a leap into SOLID but way better that it initially was.

Here’s what it is all about:

as mentioned in DEV#2 all classes in the library are abstracted by interfaces
class ItemNester introduced to make it a bit cleaner to handle multiple sheets. Now it is only required to create an instance if ItemNester, give items to it and we’re good to start calculating
the most important thing: unit tests! Most of the methods are covered by unit tests. The class wasn’t built in TDD but the tests were a great aid for debugging

To enrich this post a bit I will also write here a bit of my approach to unit tests. Of course, I am using xUnit installed as a NuGet package. All tests are stored in a separate project (class library) and each class file handles tests for one class from the main project. Each test class has private execute() method and multitude of test cases.

using Xunit;
namespace ArrangerLibrary.Tests
{
   public class SpecificClassTester
   {
      private void execute()
      {
          //code that is executed in each test
      }
   }
}

using Xunit;

namespace ArrangerLibrary.Tests

{

public class SpecificClassTester

{

private void execute()

{

//code that is executed in each test

}

Sometimes execute() method may return a value and may take arguments, it depends how your test is going to work. That is so-called preparation phase and it is optional. Although some may say that a well-written test should include that. I don’t know, I only know that it is possible to write a test without that (and I actually did in my project).
Now, we can move on an actual test case. In xUnit it is nothing more than a public method that is void but inside it’s body calls some specific methods. This method should be preceded with [Fact] or [Theory] attribute. So far, I’ve used only facts and I don’t know how theories work. That test method should check something. To do that we use Assert method.

[Fact]
public void TestCase()
{
   Assert.Equal(4, 2+2);
}

[Fact]

public void TestCase()

{

Assert.Equal(4, 2+2);

}

That test above will compare 4 and result of 2+2 and if these values are equal report as passed. Of course, Assert.Equal is not the only thing you can check. You can check multiple things, for instance if a collection contains or doesn’t contain an item, check types, or if something is null. There are broad range of conditions you can check. Maybe someday (when I become more proficient) I will write something more about that.
That’s enough for today. I regret to say that but I’ve expected that to be easier and smoother but what can I do… No one ever said it was going to be easy. The good thing in that is that I don’t fell like I am wasting time. It’s a win win situation.
And in this positive attitude I’m saying goodbye 🙂