Selfelected

Sanity check, nykterhetstest

In a (unit) test I sometimes add extra tests to check the test tests what is anticipated.

user = new User(Id="A", Name = "N1")
sut.Create(user)
saved = sut.Get("A")

saved.Name.Should.Be("N1", "Sanity check we know what we have stored.")

// Act.
sut.Clear("A")

// Assert.
result = sut.Get("A")
result.Name.Should.Be(null)

Notice the “sanity check” to verify a bug didn’t set Name to null when creating the user.

My naming convention is “Sanity check” or “Nykterhetskontroll” in Swedish.
[I know the translation, word per word, is incorrect.]

Error message “Can’t bind to ‘ngIf’ since it isn’t a known property of ‘div'” solved

When testing a component in Angular you might receive the follwoting warning:

Can’t bind to ‘ngIf’ since it isn’t a known property of ‘div’

It might depend on you not declaring the component-under-test.

See this repo.

describe('AppComponent', () => {
   beforeEach(async () => {
     await TestBed.configureTestingModule({
       imports: [
         RouterTestingModule
       ],
       declarations: [
         AppComponent
       ],
     }).compileComponents();
   });
   it('should create the app', () => {
       const fixture = TestBed.createComponent(AppComponent);
       const app = fixture.componentInstance;
       expect(app).toBeTruthy();
     });
 });

The code is slightly different than the boiler plate Angular/Jasmine test code but still visualises the issue.

The row

const fixture = TestBed.createComponent(AppComponent);

Creates a component that must be declared in

declarations: [
  AppComponent
],

It took me an hour to find it due to code being convoluted.
If it saves you 5 minutes, it was worth writing this post.

Write (arrange) Act and Assert in your automatic tests

It is a good custom to write out Act and Assert in test as it helps to write the test in a clean way; and helps the next reader to understand where Arrange stops and Act begins. It helps the writer to not involuntarily write Act statements in Assert.
Like so:

myTest()
  sut = setup()

  // Act.
  sut.do()

  // Assert.
  assert(sut.value).equals(12)

The above code is too simple to make the upside of this coding standard visible but soon tests get a few lines long and commentning Act and Assert is a good idea.

I don’t bother to write out // Arrange any more as all tests start with Arrange anyway.

Well… that was not true. I have stumbled upon tests with several Arrange, Act and Assert in them. Typically for integration tests.

How I tested *every* authorisation, authorised or not

Well… I didn’t, not down to bit level. But I got closer than any time before as every business case was tested.

Don’t believe my rudimentary text below will simply answer how to do it; it will just give a raw landscape. It took me several nights and 3 iterations before I solved all the tidbits.

More important than to test that every Role could get to its authorised Product was to see that it could not get to unauthorised ditto.
So I had to test every combination.

Testing every permutation of User, Role and Product was not  feasible. Each entity has several properties and they are, mostly, not related to authorisation. Then we have 2^64 kinds of userId where most of them are not interesting and not even in use. To continue a test on “Role of type X or Y” is really a “Role is HiredInProductsCompany”.
So I sat down and extracted the if statements from the code. They were like “if loggedOn” and “if in Role x or y”. Every such statement was extracted as a method and moved into a (temporary) helper lib.

When I was sure, with visual inspection, I had caught everything, I put some business logic into thought and manipulated and rearranged the methods. They became fewer and matchable to business requirements. Gone was “if user.Role == Administrator and user.Company = product.Company” but instead “if user.IsAdministratorAtProductsCompany(product)”.

Note that during this process I have not changed any logic and, testing besides, present state could be shipped all the time.

Now I had to get rid of any technical remains. On the outside it looked ok as the method names where very descriptive in business lingua but inside the authorisation method was “if user.Id == 0” or “if challengedUser.Id == persistedUser.ID”. It was not usable since Id as integer is a technical (often a persistance layer construction) solution for recognising an entity. In business terms it is more like “user.IsPersisted” and “if challengedUser.SameAs(persistedUser)”. I continued redusing the problem space to what I really wanted to test when authorising.
This way I seriously minimised the permutations, as an authorisable User did not care about “Id” or “Name” or “BusinessPartner” but only “IsLoggedOn” and “Role”. With 6 roles that means 12 permutations. With Project I came to, say, 32 permutations and user 4. This gives in all 12*32*4=1500 variants. Not a problem to test every combination now if I just put some (business) intelligence into creating the tests. #win

Let’s say 240 of them were positive (autorised) and the rest negative.

I started with creating a simple lib for permutating every possible input and them through One Test to green light “not authorised”. Everything red should be authorised. Already here I might have found combinations that was authorised when they should not have been.

Then I, manually, created a list of every permutation allowing authorisation. Well… manually for a programmer is reducing to loops and ifs so one method could create every authorised combination of type A and one of type B. Alltogether that is, say, 10 different methods and some manual ones. They were concatenated to a list and I made the Test assert authorised and not-authorised according to this list.

So now I had a test for every kind of authorisation check testing both authorised and not authorised and tests looks like business logic.

Assert.Inconclusive and my present almost-TDD compromise

I am trying out Visual studio unit testing framework, the Microsoft alternative to, for instance, nUnit which was my old preferred testing framework (and possibly still is).

At the same time I am not in a project devoted to Test driven development so I can’t use its religion to write tests first and refuse to show any UI progress to the customer.  Right or wrong – that is how I perceive the reality around me right now.  But I do want to have tests and waiting for them I make sure I have place holders.

My compromise is to set the tests to Inconclusive  (Ignore in nUnit talk).  I guess it will come back to bite me…

What I also do is to make sure I have a test to go with every method.

        [TestMethod]
        public void AddOrUpdateTest()
        {
            Assert.Inconclusive();
            Elvis.Common.Meta.GetMethodName<BLF.Sample>(x => x.AddOrUpdate(null, null));
        }

I used the code from

http://stackoverflow.com/questions/1524290/linq-is-it-possible-to-get-a-method-name-without-a-return-type-via-linq-expressio

but I could probably use CompulsoryCat just as well.

I belive that even adhering TDD this technique is good.  There are so many times I don’t know what the classes and methods will look like before having done a simple implementation.  To write exhaustive tests for a method that will be deleted is a waste.  Better then to make sure the simple code runs and not forget to write the tests by having a yellow Inconclusive flag.