I was working in a python environment and we had lots of unit tests but worked in a more TLD style (test last development). Most of our tasks were open enough that TDD would mean doing all the design up front rather than refactoring as we went along.
My question was more about how writing the test first is meant to work in practice? Do you know what your units are meant to be? Do requirements have to be complete and explicit?
My question was more about how writing the test first is meant to work in practice?
It's meant to work in practice by putting pressure on the developers to use most of the principles of SOLID (especially LSP, ISP, and DIP), Law of Demeter (related to DIP), Design by Contract (related to LSP), YAGNI, KISS, GRASP, SOC (related to SRP), DRY code and WET tests.
The "how to" steps are the steps I cited above in the posting. It's a very fast cycle.
Do you know what your units are meant to be?
The unit test is written moments before the code that implements the functionality.
If the developer does not know what is being implemented, then how would the developer know what to implement (regardless of TDD or unit tests)?
Do requirements have to be complete and explicit?
For the unit tests, no. Unit tests are for testing units. With TDD, unit tests are a means to guide design. (q.v. Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce.)
Requirements are at the level of acceptance tests, and perhaps integration tests and system tests.
Unit tests are written by developers, to aid development. Acceptance tests (and integration tests, and system tests) are written by quality engineers to ensure what the developers created meets the requirements.
Think of it this way: you have a bolt and a nut. You can create all sorts of tests to make sure the bolt works correctly, and all sorts of tests to make sure the nut works correctly. Those are unit tests. As soon as you write tests for the bolt-and-nut, that is no longer a unit, now it is an assembly, and these are not unit tests -- they are assembly tests (which is a kind of integration test).
I was working in a python environment and we had lots of unit tests but worked in a more TLD style (test last development).
Since you are using TLD and Python, you could probably dispense with unit testing altogether, and use something like Python Contracts module, by Rob King / deadpixi. This one supports require, ensure, invariant, types, and transform. Also supports async function (aka coroutines).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I was working in a python environment and we had lots of unit tests but worked in a more TLD style (test last development). Most of our tasks were open enough that TDD would mean doing all the design up front rather than refactoring as we went along.
My question was more about how writing the test first is meant to work in practice? Do you know what your units are meant to be? Do requirements have to be complete and explicit?
It's meant to work in practice by putting pressure on the developers to use most of the principles of SOLID (especially LSP, ISP, and DIP), Law of Demeter (related to DIP), Design by Contract (related to LSP), YAGNI, KISS, GRASP, SOC (related to SRP), DRY code and WET tests.
The "how to" steps are the steps I cited above in the posting. It's a very fast cycle.
The unit test is written moments before the code that implements the functionality.
If the developer does not know what is being implemented, then how would the developer know what to implement (regardless of TDD or unit tests)?
For the unit tests, no. Unit tests are for testing units. With TDD, unit tests are a means to guide design. (q.v. Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce.)
Requirements are at the level of acceptance tests, and perhaps integration tests and system tests.
Unit tests are written by developers, to aid development. Acceptance tests (and integration tests, and system tests) are written by quality engineers to ensure what the developers created meets the requirements.
Think of it this way: you have a bolt and a nut. You can create all sorts of tests to make sure the bolt works correctly, and all sorts of tests to make sure the nut works correctly. Those are unit tests. As soon as you write tests for the bolt-and-nut, that is no longer a unit, now it is an assembly, and these are not unit tests -- they are assembly tests (which is a kind of integration test).
Since you are using TLD and Python, you could probably dispense with unit testing altogether, and use something like Python Contracts module, by Rob King / deadpixi. This one supports require, ensure, invariant, types, and transform. Also supports async function (aka coroutines).