Download to read offline
Uploaded byHristo Iliev
Agile Software Development Techniques for Daily Use
This document discusses techniques for agile software development using test-driven development (TDD). It provides examples of writing tests first before developing code and refactoring legacy code without tests by adding new features using TDD. The benefits of TDD include fast test execution, controlled development process, and no regressions. Developing code using TDD for a set data structure is presented as an example. The document also provides contacts for further information.
More Related Content
Similar to Agile Software Development Techniques for Daily Use
Agile Software Development Techniques for Daily Use
- 1. Agile Software Development Techniquesfor Daily Use. What to Do When the Sprint Starts?
- 2. What is TDD? Writea test that use the methods you haven’t written yet.
- 3. Test Last • Hardto write tests • Slow to execute tests • No tests during development • Errors leak to production • Bus factor
- 4. Test First /TDD • Code testability for free • Fast test execution • Controlled development process • No regression • Executable Documentation
- 5.
- 6. Cost of development TimeTraditional TDD
- 7. Your turn … •What to do? – develop SET • How? – Java – TDD with JUnit – Methods: size, add, contains, remove – Storage: fixed size array
- 8.
- 9. Your turn … •What to do? – develop SET • What’s left? – size – contains – add – remove
- 10. TDD = Safetynet
- 11.
- 12. Working with LegacyCode • Make code testable • Capture behaviour • Refactor • Add features using TDD
- 13.
- 14. Your turn …1/2 • What to do? – Write a test • How? – Understand the code – Write a test • Minimal code change • No bug fixes
- 15. Your turn …2/2 • What to do? – Scrap item • In stock items only • Number of scrapped • How? – TDD – Refactoring – Bugs
- 16.
- 17.
- 18.
Editor's Notes
- #2 (Georgi) Short Introduction Agile Techniques much written how to apply in practice? Structure of the presentation Hands on / exercises Examples & Small discussions = better understanding Questions during wrap-up
- #3 (Hristo) How many of you heard of Test First/TDD? How many use TDD?
- #4 (Hristo) Hard to write tests Tests are lengthy integration scenarios Code not written with testing in mind Slow to execute Integration scenarios are complex Involve real systems Require system expertise to run or debug No tests during development Manual testing at best Error prone No reproducible tests or continuous integration Late discovery of programming errors Slow turnaround Errors leak to production Direct result of no tests during development Bus Factor programmers move to other projects, other companies knowledge goes away with them
- #5 (Georgi) Code testability for free Tests written before code => code is naturally testable No additional effort to unit test – just follow usual process (TDD) Fast test execution Tests execute for a fraction of a second Tests do not use real systems, but test units in isolation Controlled development process No feature is added without a test for it New features get tested early (feedback) No regression Old features are prevented from regression Executable Documentation Tests document what the system can do in a persistent and reproducible manner
- #6 (Georgi) Executable documentation (BDD)
- #7 (Georgi) People argue that unit testing takes too much time It does Do I need to unit test? Throwaway prototypes probably don’t need to be written TDD Full scale long lived systems must be thoroughly tested. TDD is an investment that pays off in the long run Exponential vs Linear growth of cost
- #8 (Hristo)
- #9 (Georgi) Split view in Test & Code Add test isEmpty Run test –check that it fails Add in size() return 0 Run test – check that it passed
- #10 (Hristo)
- #11 (Georgi) Coding is like walking on a line Balance between adding new features and introducing no regressions Constant danger to lose balance => fear to make changes Fearful development causes the code to rot and grow out of control TDD is your safety net Anyone would try walking the line if there is a safety net It becomes fun when you know you’re safe When you have a good test harness coding becomes a fun thing to do. However TDD is no silver bullet – you still need integration tests It takes time and effort to build a good harness A bad harness does not make a good safety net If not applied correctly TDD may not work – openness and willingness to learn and experiment is required
- #12 (Georgi) Topic Modulation We saw a little TDD in previous part with its benefits and its price Can you start immediately doing TDD in the project you’re working on – probably not. Filling in the gaps If we start fresh TDD is relatively easy to pick up What should we do in real projects that were started the old-fashioned way? Problems Code is not testable. We do not understand what the code does. We are afraid to change the code because we may break something. Legacy Code = Code without tests Codebase with tests Relatively easy to add new tests We can make changes and be relatively sure we are not introducing regression If the codebase is ugly, imperfect, has bugs, etc, we have the confidence to improve it (refactor) Codebase without tests Code not testable, which means it is hard to write tests No tests make it hard to guarantee that we do not introduce regression This make us reluctant and afraid to make changes Fearful development causes the code to rot and grow out of control Not to mention that it is not fun at all
- #13 (Hristo) Make code testable Dependency breaking techniques – we’ll see them later Test the smallest possible unit in isolation – minimalistic tests are cheaper to write and maintain Make small and conservative changes – we do not have tests yet, so change can be dangerous Testability over Aesthetics: code might look uglier, but it should be testable Capture behaviour Write tests that capture how the system behaves Do not fix bugs yet – bugs are part of the code’s behaviour Refactor Once the system is tested we may want to do some refactoring It can improve code’s aesthetics (make it cleaner, more readable) Add new features TDD Take small steps – they are easy to revert if you happen to introduce regression Scope Of Testing: Do you have to put the whole system into a harness in one go? Gradually islands of tested code will emerge. Eventually these islands will grow and form continents.
- #14 (Hristo) Computer system (Cache Register) with fiscal device Компютърна система вързана с фискално устройство
- #15 (Hristo) Tests will guarantee we do not break code enable change No code changes or bug fixes bugs are part of the API - customers rely on it we have no tests yet – cannot guarantee we don’t break code
- #16 (Georgi) Scrap functionality best before scrap items TDD possible because we have tests for the code code is testable Bugs Fix with care Do not change behaviour – customers may depend on it Expose new methods Big (time consuming) bugs should be just reported
- #17 (Georgi) If there is time – explain briefly the changes If no time – just point out the link
- #18 (Georgi)