Create helpers to ease unit testing about transit_model HOT 5 CLOSED

What we note is that with unit tests we cannot cover every cases.
And it's easier to create fixtures than create model.
But if a piece of code need to be unit tested and has a value, we "unit test" it.

from transit_model.

Edit: sorry @datanel didn't saw your reply before posting 😛
I think a model creation is way easier to understand than fixture (but fixture are really useful too!).
Unit tests are not really great for parsing NTFS/GTFS/Netex, but I think they could be a great asset business logic like transfer creation, merging (and real time applying 😆 )

I'll try to make a proposal.

What do you think of:

 let model = ModelBuilder::default()
    .vj("toto", |vj_builder| {
        vj_builder
            .st("A", "10:00:00".into(), "10:01:00".into())
            .make_st("B", "11:00:00".into(), "11:01:00".into(), |mut st| { // <-- could a stop creation with total access to the object be useful for complex initialization ?
                st.boarding_duration = 12;
            })
    })
    // .vj(...)
    .build();

We could also go for something with less lambda (but then it cannot be chained):

let mut builder = ModelBuilder::default();

builder
    .vj("toto")
    .st("A", "10:00:00".into(), "10:01:00".into())
    .make_st("B", "11:00:00".into(), "11:01:00".into(), |mut st| {
        ...
    });
    // builder.vj(...);
let model = builder.build();

what do you think ? do you see better/simplier api ?

from transit_model.

why you cannot chain in the 2nd proposition if you always return a builder?

from transit_model.

because .vj(..) will return a VJBuilder and not a builder (to mutate the current vj)

we could return a Builder and make .sa(...) work on the last vj but I'm not a fan of such implicit stuff

from transit_model.

Some work still need to be done, but it's usable for the moment, I think we can close this

from transit_model.