0% found this document useful (0 votes)
65 views49 pages

Unit3 TDD CI

This document provides information about test-driven development (TDD) and continuous integration. It discusses how TDD works using a red-green-refactor process of writing tests first, then code to pass tests, and refactoring code. It provides examples of applying TDD to a card game. Continuous integration is defined as integrating code changes continuously and includes using source code repositories, establishing a check-in process, automated builds, and working in small chunks. References are provided for further reading.

Uploaded by

Khushbu Bora
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
65 views49 pages

Unit3 TDD CI

This document provides information about test-driven development (TDD) and continuous integration. It discusses how TDD works using a red-green-refactor process of writing tests first, then code to pass tests, and refactoring code. It provides examples of applying TDD to a card game. Continuous integration is defined as integrating code changes continuously and includes using source code repositories, establishing a check-in process, automated builds, and working in small chunks. References are provided for further reading.

Uploaded by

Khushbu Bora
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 49

This document is for private circulation only,

For Final Year BTech. Computer 2021-22 CCOEW students.

Subject: Software Engineering

PLEASE refer TO ALL REFERENCES plus Study Material


CIRCULATED plus Lecture Recordings.

Feel free to use additional web sites/searches for


understanding if required.
ACKNOWLEDGEMENT
• This presentation contains pictures, contents taken
from multiple sources, authors and sites.

• We would like to appreciate and thank the authors,


artists and do not claim any of following work to be
ours, but it has been compiled here to use for academic
purpose only.
Unit 3
Agile Project Planning and Software Practices
• Agile Project Inception
• User stories
• Estimation,
• Agile plan
• Agile software practices:
- Refactoring, Test-driven development
- Continuous integration.
Reference
• Jonathan Rasmusson, 'The Agile Samurai: How Agile
Masters Deliver Great Software', Shroff Publishers and
Distributers (SPD), (2016).
- Chapters 3, 4, 5, 6, 7, 8, 13, 14, 15
Test-Driven Development
Test-driven development (TDD) is a software development
technique that uses really short development cycles to
incrementally design your software.

Test First Approach


Source: Internet
Write Your Tests First - How TDD works
1. Red: Before you write any new code for the system, you
first write a failing unit test, showing the intent of what you
would like the new code to do. Here you are thinking
critically about the design.

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Write Your Tests First - How TDD works

2. Green: Then you do whatever it takes to make the test pass.


If you see the full implementation, add the new code. If
you don’t, do just enough to get the test to pass.

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Write Your Tests First - How TDD works
3. Refactor: Then you go back and clean up any code or sins
you committed while trying to get the test to pass. Here
you are removing duplication and making sure everything is
lean, mean and as clear as possible.

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Passing all the story’s acceptance criteria.

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Test Driven Development

Source: http://agiledata.org/essays/tdd.html
Test-Driven Development
• In TDD, unit testing is carried out on the source code
directly.

Source: https://reqtest.com/testing-blog/tdd-and-atdd-an-overview-of-the-two-popular-methods-2/
Rules of Thumb
• Rule #1: Don’t write any new code until you first have a
failing test.
– not to write any more code than absolutely necessary.

• Rule #2: Test everything that could “possibly” break.


– If there is a plausible chance that something might break
or we want to show intent in how the program will
behave under certain conditions, we write a test for it.

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Use the Tests to Deal with Complexity
• By writing your tests first and ensuring you have a failing test
before adding the new code, TDD helps you fight the sheer
amount of complexity you and your team are going to face
writing code every day.

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Use the Tests to Deal with Complexity

• TDD also gives you a way of designing with confidence. By


focusing on a single test and making it pass, you don’t have to
keep a thousand things in your head at once.

• You can focus on one little problem, learn incrementally how


to best tackle it and get the instant feedback you need to tell
you whether you are headed in the right direction.

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Other Reasons for Doing Test-First

With less code comes less complexity. And with a simpler design,
making changes and modifications becomes a lot easier.

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Example
• Write the method name you would like to see on the Card
class that compares two cards and tells whether one is greater
than the other.
• Step 1

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Example

• Step 1:

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Example
• Step 2:

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Example
• Step 3: Refactor

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Test Driven Development

• It is difficult to add Unit tests to an existing


program because the program probably wasn’t
written with testing in mind.

• It’s actually better to write the tests before writing


the code you want to test.
Test Driven Development
• This seems backward, but it really does work better:
o When tests are written first, you have a clearer idea what
to do when you write the methods.
o Because the tests are written first, the methods are
necessarily written to be testable.
o Writing tests first encourages you to write simpler, single-
purpose methods.
o Because the methods will be called from more than one
environment (the “real” one, plus your test class), they
tend to be more independent of the environment.
TDD Example
Requirement: The password should
be between 5 to 10 characters.

Source: https://www.guru99.com/test-driven-development.html
Step 1 - Write a Test

• Test fails as the PasswordValidator code not written.

Source: https://www.guru99.com/test-driven-development.html
Step 2 - Write PasswordValidator code

• Test passes.

Source: https://www.guru99.com/test-driven-development.html
Step 3 - Refactor
• In method TestPasswordLength (), there is no need of
creating an instance of class PasswordValidator.

• Test fails as isValid() is a non-static method.

Source: https://www.guru99.com/test-driven-development.html
Step 4 - Refactor

• Test passes.

Source: https://www.guru99.com/test-driven-development.html
ACKNOWLEDGEMENT
• This presentation contains pictures, contents taken
from multiple sources, authors and sites.

• We would like to appreciate and thank the authors,


artists and do not claim any of following work to be
ours, but it has been compiled here to use for academic
purpose only.
Continuous Integration
Source: https://www.edureka.co/blog/what-is-jenkins/
Earlier…

Source: Internet
• Things we want to eliminate or at least manage.
• Production readiness - be able to demo our product to
anyone, anytime, anywhere.

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
What Is Continuous Integration?

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
What Is Continuous Integration?
• Continuous integration is the act of continuously
taking changes developers make to their software
and integrating them all together continuously
throughout the day.
Work in Small Chunks
• Just like testing with TDD, integrating code is much easier
when done in the small.
• Merge your code early and often to avoid the pain of big
integrations.

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
How Does It Work?
• A source code repository
– Store and version your software.
– Open source repositories like Git or Subversion.

• Establish a Check-in Process

• An automated build

• A willingness to work in small chunks


Source: https://www.slideshare.net/nishanthnow/introducing-devops
Source: https://techbeacon.com/devops/are-you-really-doing-continuous-integration-heres-how-tell
Source:
https://documentation.b2c.commercecloud.salesforce.com/DOC4/index.jsp?topic=%2Fcom.demandware.dochelp%2FLegac
yDevDoc%2FContinuousIntegration.html
Establish a Check-in Process

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Establish a Check-in Process
1. Get latest source from the repository.
– Check out the latest build and start your work with a clean slate.
2. Make changes.
– Add the new functionality, fix the bug, or do whatever work needs
to be done.
3. Run tests
– Make sure the changes you made haven’t broken something else in
the code base, run all tests to make sure they all still pass.
4. Check for any more updates.
– If someone made some changes while you were doing your work.
5. Run tests again.
– Your changes work with whatever other changes others have made
6. Check-in.
– Everything builds. All the tests run.

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great Software', Shroff
Publishers and Distributers (SPD), (2016).
Create an Automated Build

• A good automated build compiles the code, runs the


tests, and basically does anything that regularly needs to
be done as part of the project’s build process.

• Developers run it all the time as part of the TDD circle of


life, and build agents use it to run the build whenever
they detect a change in the source code repository.
Create an Automated Build

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Create an Automated Build

• Automated builds can also automate deploying the software


into production and remove a lot of the human error from
that equation.

Source: Jonathan Rasmusson, 'The Agile Samurai: How Agile Masters Deliver Great
Software', Shroff Publishers and Distributers (SPD), (2016).
Create an Automated Build
• The key to any build is automation—the less human
involvement, the better.
• You also want to keep your build fast, because you and your
team are going to be running constantly, many times per day
(under ten minutes is a good rule of thumb).

• Most modern languages have their own automated build


frameworks (Maven, Ant for Java, NAnt or MS-Build for .NET,
and rake for Rails).

• If the language you are using doesn’t, you can usually create
your own with DOS bat files or Unix scripts.
Continuous Integration Tools

• Jenkins
- Test automation, configuration management, continuous
integration and continuous delivery
Source: https://anarsolutions.com/deploy-your-net-applications-azure-with-jenkins/
ACKNOWLEDGEMENT
• This presentation contains pictures, contents taken
from multiple sources, authors and sites.

• We would like to appreciate and thank the authors,


artists and do not claim any of above work to be ours,
but it has been compiled here to use for academic
purpose only.

You might also like