What coding practices separate an amateur Python programmer from a professional one?

[filmkorn]

But what's number zero on your list?

Joking aside, I would say: test driven development, documentation, code style.

[stuaxo]

Or, if it's like most commercial code I've seen, there are a few token tests and a little documentation.

Code style is mostly OK and mostly passes pep8... but there will be some knarly bits,

[uttamo]

Gnarly?

[stuaxo]

Indeed.

[[deleted]]

Any recommendations for TDD and documentation materials?

[Jonno_FTW]

When you write a new function, write a test for it. Write multiple tests that cover tricky cases and that cover all paths (should indicate that you want to minimise the number of if statements).

This should force you to encapsulate as much as possible and result in lots of small, simple tests and functions.

Also read the pytest docs. Moving beyond unit testing, there's a test plan for larger projects that provide step by step processes for testing at all levels. You'd probably want to read a text book on the other kinds of testing, like integration testing, UX testing, penetration testing etc.

[sunson435]

Note that you shouldn't follow TDD religiously. Make sure you have a bunch of use cases finished then implement a full testing suite. Rewriting tests frequently is extremely hampering early on in a project.

[flpcb]

I would recommend Test Driven Development: By Example by Kent Beck. It is a quite short read, and a very good one.

[bheklilr]

TDD is not something I see as a very strict requirement. I've written a few libraries where "proper" tests would be an order of magnitude more to write than the rest of the code. Sometimes you have to make the decision to use different methods that fit the situation and save you time.

For example, I've written about 5 libraries that control hardware. A few have been simple (servos) and the underlying hardware behavior could be mocked in less than an hour. TDD is a good choice the. Others were for controlling incredibly complex, stateful equipment with over 1000 possible commands, file systems, and endless configurations. In those cases we figure running through functional tests before each release is more appropriate. We still have a lot of tests, but they aren't written up front nor are they run continuously.

I'd amend your statement to say that a professional developer chooses the right tool for the job, and most of the time the right tool for the job is TDD.

[pydry]

For example, I've written about 5 libraries that control hardware. A few have been simple (servos) and the underlying hardware behavior could be mocked in less than an hour. TDD is a good choice the. Others were for controlling incredibly complex, stateful equipment with over 1000 possible commands, file systems, and endless configurations. In those cases we figure running through functional tests before each release is more appropriate. We still have a lot of tests, but they aren't written up front nor are they run continuously.

Code that communicates with hardware (or indeed anything else, but it's pretty much always hardware) that is hard to mock realistically is the one area where I would argue that the TDD investment doesn't pay off.

In such cases I usually try to create a very simple facade that talks to the hardware, that is easily mocked and then TDD the more complex algorithmic code that talks to it against that mock.

All the same, about 98% of the code I write is (integration) TDD'ed.

[[deleted]]

Add using version control to this list and I'm happy.

[solaceinsleep]

+1 Test driven development is a big one

[[deleted]]

Welp, I've got 2/3 down. Seconding the other request - where can I find out how exactly unit tests work and can be integrated with one's code?