I've informed you I'll be doing Business Logic for Biking Endorphines.
To make best of my time I've considered to go with TDD and that's why I'll first implement Tests for Business Logic.
This will propably shape all business logic, but I'll have already tests with myself for future.
Prerequisites - Business Logic
1. Business logic for Biking-Endorphines.
So the Business Logic for Biking Endorphines is going to be Endorphines badges algorithms themselves.
Just as I've revealed in behind-closed-doors, type of algorithms for endorphines badges will be:
- Adventure style - Calculate how you could change your route to (shorten/lenghen/alternate) your ride-path
- Training style - to keep up with every-day motivation for training - i.e. showing how your timing can change by training today.
- Family style - to find exciting places that you didn't know about and to share this experience with family.
And others that I currently haven't figure-out yet.
2. Why I will start my implementation of B-Logic with tests?
So first of all, the TDD approach in my opinion is something beautiful in it's core. You first create tests for functions/methods/classes that will make your b-logic.
This tests will fail at beginning. But they will also keep you motivated to keep-up with code and give you path by which you should follow when creating code-itself.
Lately I've watched YT talk about Super is Super - by Raymond Hettinger That I was really impressed about!
I might think about using TDD and the
Super is Super in my implementation.
My limited resources made me create only simplest tests for pre-existing code and some "NotImplemented" tests that will need to be created in future.
I've found out that if you put "NotImplementedError" as return in tests, this test-function than does not fail!