Bank Kata - Python - Codurance Screenkata

In this video Pablo Martinez, Software Craftsperon at Codurance, improved a solution to the Simple Mars Rover kata written in Typescript.

Pablo is excited to share this approach as he feels it can be useful for those learning Python that have already done the kata in other languages.


#kata #coding #tdd #software #python #pythonprogramming #pythontutorial #pythonforbeginners #pythonprojects

[matheusaugustodasilvasanto]

Excellent screencast. I concur with the other commenter, about the size of the text in the video. Nevertheless, the video was still pretty enjoyable (watching on a laptop).

The implemented solution is neat, here are the things I would've done differently if I were to solve the problem (again):

1. There seems to be a missing concept in the code, of a "rolling balance"; perhaps a new data structure should've been created, with a reference to a transaction and an extra field for a rolling sum of the balance before or after that transaction (would need to experiment to see what feels more natural).
With this, the print function could've received an iterable of these structures and kept all printing logic to itself.
Right now the account service knows that there needs to be a header and a print call for each transaction, and I'm not sure I like that. (What if you also need a footer? What if you need no header? What if you want to paginate and group the print statements for every N transactions? Etc. Etc.)

2. The stdout redirection seems very fragile.
The developer is constantly one missed line away from forgetting to revert the stdout redirection, leaving the test runner on a potentially inconsistent state (now I don't remember if pytest automatically reverts these sorts of things even if you forget them, but I still think it's risky).
The current solution doesn't scale well for multiple tests that use the account service's, or any other, printing function.
The redirection could benefit immensely from a context manager. In fact, contextlib.redirect_stdout (3.4+) does exactly what one needs in this situation!
I also believe pytest has facilities for interacting with stdout and stderr well, but I'd need to review the docs.

3. Lastly, the test does not tell a clear story of when each transaction occured. I think it would've been better to take advantage of python's context managers.

with transaction_at_date(...such and such date...):
account_service.deposit(500)
with date...):


This adds duplication, but the duplication could be dealt with by extracting the operations into a list of (date, operation, value) tuples, and a loop that iterates through it (and many more options, this is just the first that came to mind).
Well-implemented CMs and facilities could be reused across tests, helping with maintainability.

Finally:

Please don't take what I'm saying as adversarial, I just love talking software engineering and design! 😁 I recognize that in a screencast there's limited time, and implementing production-ready solutions isn't really the focus, instead being the sharing of ideas and techniques which this video does quite well! Furthermore, I have the benefit of not having my hands on the keyboard or an audience to entertain, leaving my mind free to wonder about the design. I believe this is one of the stronger arguments in favor of pair programming haha.

And so, thank you for this excellent material. The world needs more of this and less of "pop-culture" programming that seems to inundate social media nowadays. Best of luck on your ventures, and please keep educating the world!

[DannyJones]

Impossible to read the code on an iPad. Please consider who you’re recording these things for, so much wasted space and tiny text. I’m sure the content itself is great, shame I couldn’t see it.