Test-driven development (TDD) writes automated tests before implementation. The tests specify how a tool or feature should behave, then code is written until the tests pass. section 8.5 section 20.3
A practical TDD cycle looks like this:
- Describe the intended behavior through usage examples or tests. section 8.5 section 20.3
- Run the tests and confirm that the new feature initially fails. section 20.3
- Implement the feature incrementally until every test passes. section 20.3
- Keep tests for unusual failures so later changes cannot silently forget those conditions. section 20.3
Specify a machine-information tool
Usage examples such as Get-MachineInfo -ComputerName CLIENT, pipeline input, and optional failure logging expose the desired interface before implementation. If the examples become unwieldy, simplify the tool design or split responsibilities. section 8.5
Get-MachineInfo -ComputerName CLIENT Get-MachineInfo -ComputerName CLIENTA,CLIENTB Get-MachineInfo -ComputerName (Get-Content names.txt) Get-MachineInfo -ComputerName (Get-ADComputer -id CLIENTA | Select -Expand name) Get-Content names.txt | Get-MachineInfo Get-ADComputer -id CLIENTA | Select -Expand name | Get-MachineInfo
Compare direct arguments, lists from files, directory-service results, and pipeline input as concrete behavioral specifications for one command. section 8.5
