Create Tests for TimeSpan

[thinkrapido]

Is your feature request related to a problem? Please describe.
We need a thorough testing of the TimeTpan struct, as it's the basis for all scheduling efforts.

Describe the solution you'd like
There should be also test cases like we have for scheduler tests.

Input

[
        {
            "filter": {
                "after": "17:00",
                "before": "02:00"
            },
            "days": ["Sunday", "Monday"]
        },
        {
            "filter": {
                "after": "08:00",
                "before": "11:00"
            },
            "days": ["Weekends"]
        }
]

should be checked with fixture

Sat    06:00  12:00  18:00  Sun    06:00  12:00  18:00  Mon    06:00  12:00  18:00 ``
|######`##...#`######`######|######`##...#`#####.`......|..####`##...#`#####.`.....|

Describe alternatives you've considered
Alternatively, we could implement those tests within test files like already existent in timespan.rs, but this would be tedious.

Additional context

running 1 test
 Sat    06:00  12:00  18:00  Sun    06:00  12:00  18:00  Mon    06:00  12:00  18:00
|######`##...#`######`######|######`##...#`#####.`......|..####`##...#`#####.`.....|
test models::timespan::test::timespan_test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 3 filtered out; finished in 0.00s

[tijlleenders]

@thinkrapido
Agree that, in line with the general TDD approach, tests should be written for this struct. I guess this fits in with the next tests we're trying to get green #425?

Initially the unit tests for 'TimesSpan' would only be constructor tests: do we get the right struct when passing in a variety of combinations possible for the constructor input. These are unit tests int /src/tests - not end-to-end tests in /tests. There are a lot of 'legacy tests' still there that can be removed or refactored if the concepts match.

However I have a side-comment: #428 (comment)

[tijlleenders]

@thinkrapido

• Shouldn't we leave the 'Weekends' concept to the frontend presentation layer?
• If these are unit tests - the input/output should be Rust code right, not json?
  Although your approach of using serde is quite readable and avoids additional constructor code. I like that.

[thinkrapido]

won't do