This document provides an overview of test driven development (TDD), continuous integration (CI), continuous delivery (CD) and continuous deployment. It defines TDD as writing tests before code to guide development. CI involves integrating code into a shared repository daily and automating builds and testing. CD allows software to be released to production at any time if all tests pass. Continuous deployment automatically deploys software to production whenever changes are merged into the main branch. The document discusses benefits like higher quality, faster delivery and flexibility, and recommends automating everything and having developers and operations work together.
2. Agenda
• Section: 1
• What is TDD?
• Why do we need to use it?
• How do we use it?
• Section 2:
• What is CI?
• What Continuous Delivery &
Continuous Deployment?
• Why do we use CI/CD?
• How do we use it?
• Section 3:
• CI/CD - Demo
3. TDD ( Test Driven
Development)
• “Test Driven Development
(TDD) is a technique for
building software that guides
software development by
writing tests” –
Martin Fowler’s Definition
4. Step 1: Write test that fails
• Red - Write a little test
that doesn’t work,
perhaps doesn’t even
compile at first.
5. Step 2: Make test pass
• Green - Make the test
work quickly, committing
6. Step 3: Refactor/ Cleanup code
• Refactor – Eliminate all
the duplication and
smells created in just
getting the test to work.
8. Assertions
• Assertions verify that expected conditions are met. Each assertion
has different overloaded methods to accespt different parameters.
• assertTrue
• assertFalse
• assertNull
• assertNotNull
• assertEquals
• assertNotEquals
• assertArrayEquals
• assertIterableEquals
• assertSame and assertNotSame
• assertAll
• assertThrows
• assertTimeout
• assertLinesMatch
• fail
9. Different Annotations in Junit and Jupitor
JUnit4 Junit Jupitor
@Before @BeforeEach
@After @AfterEach
@BeforeClass @BeforeAll
@AfterClass @AfterAll
@Ignore @Diabled
@Category @Tag
@RunWith @ExtendWith
10. JUnit – Assert
Hamcrest
• Using Assert:
Assert.assertEquals(“Shan”, user.firstName());
//or Using Assert static imports
assertEquals(“Shan”, user.firstName());
• Using Hamcrest
MatcherAssert.assertThat(user.firstName().IsEqua
l.equalTo(“Shan”));
//Or Using static imports
assertThat(user.firstName(), equalTo(“Shan”));
11. Mockito
EasyMock
JMock
• Methods under test often leverage
dependencies
• Test with dependencies created challenges
• Live database needed
• Multiple developers testing simultaneously
• Incomplete dependency implementation
• Mocking frameworks give you control
• Implement the mocked functionality in a class -
Tedious & Obscure
• Leverage a mocking framework
• Avoid class creation & Leverages the proxy
pattern
12. Creating Mock
Instances
• Mockito.mock(Class<?>class) is the core
method for creating mocks
• @Mock is an alternavtive
• Example
Class BookServiceTest {
protected @Mock BookDao mockBookDao;
@Before
public void setup(){
MockitoAnnotations.initMocks(this);
}
}
13. Using
MockSettings
• The MockSettings interface provides added
control for mock creation
@Test
Public void test_getBookDetails {
MockSettings settings = Mockito.withSettings();
BookDao mockBookDao =
Mockito.mock(BookDao.class, settings);
}
14. Mockito
• Support Unit testing Cycle
• Creating the Mock
BookDao mockBookDao = Mockito.mock(BookDao.class)
• Setup – Method Stubbing
Mockito.when(mockBookDao.findByTitle(bookTitle)).thenReturn(BookFixture)
• Verification
Mockito.verify(mockBookDao).findByTitle(bookTitle)
Setup Execution Verification Teardown
15. Mockito -
Verification
• Mockito.verify(..) is used to verify an intended
mock operation was called
• Example
• Setup
Mockito.when(mockBookService.getBookDeta
ils(bookId)).thenReturn(bookDetail);
• Verification
Mockito.verify(mockBookService).getBookDet
ails(bookId);
16. Verification –
Cont.
• VerificationMode allows extra verification of the operation
• Times(n)
• atLeastOnce(n)
• atLeast(n)
• atMost(n)
• Never()
//setup
Mockito.when(mockBookService.getBookDetails(bookId)).thenRe
turn(bookDetails);
//verification
Mockito.verify(mockBookService,
VerificationSettings.times(2)).getBookDetails(bookId);
• Verifying no interactions globally
• Mockito.verify(..).zeroInteractions()
• Mockito.verify(..).noMoreInteactions()
17. Test Fixtures
• A Test fixture is a fixed state of a set of objects
used as a baseline for running tests.
• Ensure that there is a well known and fixed
environment in which tests are run so that
results are repeatable.
• Type of Fixtures:
• Object
• Mock
• Database – DataSet, Query DataSet,
Replacement DataSet
• Files – Excel, XML, FlatXML
18. Section: 2
CI/CD&CD
What is Continuous integration?
What is Continuous Delivery?
What is Continuos Deployment?
Why do we need to use it?
How do we use it?
CI/CD – What are the frameworks available to do
ci/cd?
Demo!
19. CI/CD – Cont.,
• Agile
• Refactor
• Educate Everyone
• Be Small
• Practice TDD
Define Your CD Pipeline As Code
• Have a Fast Pipeline
• Consider Fixing a Failed Pipeline As Highest
Priority
• Run the CD Pipeline
• Commit only to the Master Branch(Single
branching strategy) Or (Use Short-Lived Feature
Branch)
20. Continuous Integration
• Continuous Integration
(CI) is development
practice that requires
developers to integrate
code into a shared
repository serveral times
a day
21. CI Principles
Have a single place where all the code lives
Everyone commits to the mainline every day
Automate the build process
- Fix the broken build immediately
- Make and keep the build fast
Every commit triggers a build
Automate the testing process
Everyone has access to the latest results
Everyone can see everything
22. CI Benefits:
Integration takes less effort
Issue will come up more early
Automation means less issues
The process is more visible
Improved team communication
Short Integration iterations means more flexibility
The code is ready to be delivered more often
24. Integration
High Chance of Errors(Bugs & Reworks)
Defects are found late(Causing extra works)
Lots of effort in integration
Difficult to reproduce the release
Can only release once per iteration
25. Release
• High Chance of Errors
• Lots of effort in deployment
• Difficult to reproduce deployment
• Inconsistency in environments
• Deployments are scary
• slow delivery of functionality
26. CI: Summary
Continuous Integration
• Integrate centrally every day
• Automate
• Build
• Test
Higher Quality
Faster Delivery
Lower Costs
More Flexibility
27. CD – Continuos Delivery
• Continuous Delivery is a
Software discipline where
software can be released
to production at any time
28. Continuous Delivery
QA
Developers Manual Test
Release Approval
Operations Build Pipeline Release Pipeline
SC Build Test deployCreate Test
ProdOn DemandAutomated
29. CD
Principles
Have Continuous integration in place
Development and Operations should work well together
Treat Infrastructure as a code artifact
Automate the environment creation process
Automate the release process
- Automate acceptance tests
Include release do definition of done
Releasing should be on-demand
Everyone has access to the latest result
Everyone can see everything
30. CD Benefits:
Releasing take less effort
Releasing is more
- Reliable
- Repeatable
Put control of release in the hands of business
Release more often
Get feedback earlier
