Fork me on GitHub

So I was hoping to get some advice about the properties I could test for the convert function found at


testing the string generated by convert will be a bit annoying


but you could test the functions that it uses


some easy ones, do any of them return a negative month, day, year


or a month larger than 12 (or 11 if 0 indexed), day greater than 31, tec


I understand testing the boundaries aren’t crossed like you mentioned. If I returning a map rather than string, with day, month and year keys, it would be easier to ‘parse’ and thus test. Would quickcheck style testing help then?


Would I use it to test the function actually returns the correct resultant date? I was thinking that I would have to model the gormanic calendar in the test, and for a random set of input dates, ensure convert would return the appropriate gormanic date. But this would be in effect duplicating SUT code in the test?


Apologies, if I’ve asked a common question, I’ve watched a few videos etc but many properties seem abstract, or away from the concrete problem if that makes sense?


Yeah, a map definitely seems easier


I don’t know enough about the gormanic calender to provide some good properties there 😕


The wikipedia page isn’t all that much help, heh


One idea is if you could provide a comparator function for both date types, and make sure that if one random date is greater than another random date in the gregorian calender, then it’s also greater in the calculated gormanic calender date.


hehe, oh sorry, the gormanic calendar is made up for a kata. okay, I need to think about your idea for the comparator function. If I developed one, would you not simply say that for all inputs, the output compares exactly to the input?


okay. Cheers, let me think about that and I’ll have a play.