I frequently do TDD with integration and end to end tests. The type of test should be dictated by the nature of the code, which TDD doesnt have an opinion on.
TDD is about following red-green-refactor.
TDD lets you safely forget by tying the test pass/failure directly to the code.
So, yes, you can do test-after but why?
The only reason Ive ever heard for doing it after anyway is "I just prefer it that way".
Not writing tests at all makes sense (e.g. for a spike), but if I were going to start writing tests at any point I cant see any reason not to do it with TDD.
Also the higher level you test at, the less probable that you have to change the tests when you change a piece of functionality.
Learn about other kinds of (much more effective) testing like System/Integration testing, Property-based testing. Spend a lot of time learning about databases and SQL. Maybe get into somewhat esoteric topics like constraint solvers and logic programming. You may not use these but it helps to know there's a wide world out there, and they do bend your brain enough to enable you to think differently.
Time is limited. It does matter what we spend it on.
Also they have Python (and less relevant to me) Javascript libraries. So I assume you dont have to go through LangChain anymore.
"The Soul of Erlang and Elixir • Saša Jurić • GOTO 2019" - https://www.youtube.com/watch?v=JvBT4XBdoUE
When you feel sufficiently amazed by this demo, I also recommend the Elixir in Action book, by this same author, to get started with this incredible ecosystem and paradigm.
---
It's hard to imagine a better platform than Erlang's for writing distributed and networked systems of any kind. I fell in love with Elixir in 2016 and have been using it full time since, first adopting as CTO in my previous company, now powering my new solo business. It's such a good language, with great community and stewardship, running on a rock solid platform that's so advanced compared to most popular languages today.
Erlang was created 38 years ago, and it's good to see the ideas of Armstrong, Virding and Williams to be vindicated today. They simply were too far ahead of their time.
I don't recall ever needing anything other than virtualenvwrapper and pip—and even some of the annoyances these tools had early on have been solved by now...
https://virtualenvwrapper.readthedocs.io/en/latest/
If you really need different versions of python, you can just `mkvirtualenv -p python3 venvname`
I feel like every other tool out there has to explain what problem they solve that virtualenvwrapper doesn't
Don't install anything globally, creates lots of envs, and feel free to have different versions of python installed side-by-side with some "main" version preferably symlinked as `python` and `python3`
The end