Programming workshop
5:15 pm
Student program
Pycharm
jetbrains.com/pycharm
jetbrains.com/student
Intellij IDEA
jetbrains.com/idea
PhpStorm
jetbrains.com/phpstorm
And the list goes on…
Workshop samples code
https://github.com/aganezov/java-samples.git
What is TDD?
Test-driven development (TDD) is a software development
process that relies on the repetition of a very short development cycle:
first the developer writes an (initially failing) automated test case that
defines a desired improvement or new function, then produces the
minimum amount of code to pass that test, and finally refactors the
new code to acceptable standards. Kent Beck, who is credited with
having developed or 'rediscovered’ the technique, stated in 2003 that
TDD encourages simple designs and inspires confidence.
Wikipedia
What is TDD?
Test-driven development (TDD) is a software development
process that relies on the repetition of a very short development cycle:
first the developer writes an (initially failing) automated test case that
defines a desired improvement or new function, then produces the
minimum amount of code to pass that test, and finally refactors the
new code to acceptable standards. Kent Beck, who is credited with
having developed or 'rediscovered’ the technique, stated in 2003 that
TDD encourages simple designs and inspires confidence.
Wikipedia
What is TDD?
Test-driven development (TDD) is a software development
process that relies on the repetition of a very short development cycle:
first the developer writes an (initially failing) automated test case that
defines a desired improvement or new function, then produces the
minimum amount of code to pass that test, and finally refactors the
new code to acceptable standards. Kent Beck, who is credited with
having developed or 'rediscovered’ the technique, stated in 2003 that
TDD encourages simple designs and inspires confidence.
Wikipedia
What is TDD?
Test-driven development (TDD) is a software development
process that relies on the repetition of a very short development cycle:
first the developer writes an (initially failing) automated test case that
defines a desired improvement or new function, then produces the
minimum amount of code to pass that test, and finally refactors the
new code to acceptable standards. Kent Beck, who is credited with
having developed or 'rediscovered’ the technique, stated in 2003 that
TDD encourages simple designs and inspires confidence.
Wikipedia
See the test fail and then test pass
See the test fail and then test pass
See the test fail and then test pass
See the test fail and then test pass
Helps you find bugs in your test code!!!
Different types of tests
• Unit tests
• (Incremental) Integration tests
• API tests
• System testing
• End-to-end testing
Different types of tests
• Unit tests
• (Incremental) Integration tests
• API tests
• System testing
• End-to-end testing
• Regresstion testing
• Acceptance testing
• Stress / Perfromance testing
• Usability testing
• Install / unistall testing
• Compatibility testing
• Alpha / Beta testing
Unit testing
Unit testing
Xkcd.com
Unit testing
Intuitively, one can view a unit as the smallest testable part
of an application. In procedural programming, a unit could be
an entire module, but it is more commonly an individual
function or procedure. In object-oriented programming, a unit
is often an entire interface, such as a class, but could be an
individual method.
Wikipedia
Unit testing
Unit testing finds problems early in the development cycle. This
includes both bugs in the programmer's implementation and flaws
or missing parts of the specification for the unit.
Unit testing
• Separate common SetUp /
TearDown approach for test
refactoring
• Keep each test oracle
to focused on only the result
necessary to validate the test
• Treat you test code with the
same respect you would treat
your production code
• DO test reviews
DO DO NOT
• Make tests / class
state depend on the previously
executed tests
• Test implementation details
• Create slow running tests
• Create Interdependent tests
Integration testing
Integration testing
Simply, test that different component parts of your system
integrate correctly - for example - maybe you simulate a
web service request and check that the result comes
back. I would generally use real (ish) static data and
mocked dependencies to ensure that it can be
consistently verified.
Integration testing
1.Big Bang
2.Bottom Up
3.Top Dowm
Integration testing
Testing takes place from the
bottom of the control flow
upwards. Components or
systems are substituted by
drivers.
istqbexamcertification.com
Integration testing
• In this approach development
and testing can be done
together so that the product
or application will be
efficient and as per the
customer specifications
pros cons
• We can catch the Key interface
defects at the end of cycle
• It is required to create the
test drivers for modules at
all levels except the top
control
Bottom Up
Integration testing
Testing takes place from top to
bottom, following the control
flow or architectural structure
(e.g. starting from the GUI or
main menu). Components or
systems are substituted by
stubs
istqbexamcertification.com
Integration testing
• The tested product is very consistent
because the integration testing is
basically performed in an environment
that almost similar to that of reality
• Stubs can be written with lesser time
because when compared to the drivers
then Stubs are simpler to author.
pros cons
• Basic functionality is tested
at the end of cycle
Top Down
Acceptance testing
Acceptance testing
Acceptance tests are created from user stories. The
customer specifies scenarios to test when a user story has been
correctly implemented. A story can have one or many acceptance
tests, what ever it takes to ensure the functionality works.
Acceptance tests are black box system tests. Each acceptance test
represents some expected result from the system. Customers are
responsible for verifying the correctness of the acceptance tests
and reviewing test scores to decide which failed tests are of
highest priority.
Acceptance testing
Wikipedia
Acceptance testing
Wikipedia
Important notes
• Trust your tests
• Keep your tests maintainability
• Make your test readabile
Important notes
• Testing can not be done before knowing what the project
is in general. While test can be isolated, knowledge
about the system still must be present.
• Must be a constant skeptic. Don’t be a believer. Try to
screw everything with the test as much as you can. Do
everything you want, just don’t believe.
• Pseudocode might be wrong due to over simplification.
Next JetBrains GWU meeting
“VCS – Git – Part I”
December 3, 5:00 – 7:00 pm SEH room 2000
Facebook
https://www.facebook.com/groups/jetbrains.gwu/
Twitter
https://twitter.com/JetBrains_GWU
Email
jetbrains.gwu@gmail.com
aganezov@gwu.edu

Test Driven Development

  • 1.
  • 2.
  • 3.
  • 4.
    What is TDD? Test-drivendevelopment (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence. Wikipedia
  • 5.
    What is TDD? Test-drivendevelopment (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence. Wikipedia
  • 6.
    What is TDD? Test-drivendevelopment (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence. Wikipedia
  • 7.
    What is TDD? Test-drivendevelopment (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence. Wikipedia
  • 9.
    See the testfail and then test pass
  • 10.
    See the testfail and then test pass
  • 11.
    See the testfail and then test pass
  • 12.
    See the testfail and then test pass Helps you find bugs in your test code!!!
  • 14.
    Different types oftests • Unit tests • (Incremental) Integration tests • API tests • System testing • End-to-end testing
  • 15.
    Different types oftests • Unit tests • (Incremental) Integration tests • API tests • System testing • End-to-end testing • Regresstion testing • Acceptance testing • Stress / Perfromance testing • Usability testing • Install / unistall testing • Compatibility testing • Alpha / Beta testing
  • 16.
  • 17.
  • 18.
    Unit testing Intuitively, onecan view a unit as the smallest testable part of an application. In procedural programming, a unit could be an entire module, but it is more commonly an individual function or procedure. In object-oriented programming, a unit is often an entire interface, such as a class, but could be an individual method. Wikipedia
  • 19.
    Unit testing Unit testingfinds problems early in the development cycle. This includes both bugs in the programmer's implementation and flaws or missing parts of the specification for the unit.
  • 20.
    Unit testing • Separatecommon SetUp / TearDown approach for test refactoring • Keep each test oracle to focused on only the result necessary to validate the test • Treat you test code with the same respect you would treat your production code • DO test reviews DO DO NOT • Make tests / class state depend on the previously executed tests • Test implementation details • Create slow running tests • Create Interdependent tests
  • 21.
  • 22.
    Integration testing Simply, testthat different component parts of your system integrate correctly - for example - maybe you simulate a web service request and check that the result comes back. I would generally use real (ish) static data and mocked dependencies to ensure that it can be consistently verified.
  • 23.
  • 24.
    Integration testing Testing takesplace from the bottom of the control flow upwards. Components or systems are substituted by drivers. istqbexamcertification.com
  • 25.
    Integration testing • Inthis approach development and testing can be done together so that the product or application will be efficient and as per the customer specifications pros cons • We can catch the Key interface defects at the end of cycle • It is required to create the test drivers for modules at all levels except the top control Bottom Up
  • 26.
    Integration testing Testing takesplace from top to bottom, following the control flow or architectural structure (e.g. starting from the GUI or main menu). Components or systems are substituted by stubs istqbexamcertification.com
  • 27.
    Integration testing • Thetested product is very consistent because the integration testing is basically performed in an environment that almost similar to that of reality • Stubs can be written with lesser time because when compared to the drivers then Stubs are simpler to author. pros cons • Basic functionality is tested at the end of cycle Top Down
  • 28.
  • 29.
    Acceptance testing Acceptance testsare created from user stories. The customer specifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, what ever it takes to ensure the functionality works. Acceptance tests are black box system tests. Each acceptance test represents some expected result from the system. Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority.
  • 30.
  • 31.
  • 32.
    Important notes • Trustyour tests • Keep your tests maintainability • Make your test readabile
  • 33.
    Important notes • Testingcan not be done before knowing what the project is in general. While test can be isolated, knowledge about the system still must be present. • Must be a constant skeptic. Don’t be a believer. Try to screw everything with the test as much as you can. Do everything you want, just don’t believe. • Pseudocode might be wrong due to over simplification.
  • 34.
    Next JetBrains GWUmeeting “VCS – Git – Part I” December 3, 5:00 – 7:00 pm SEH room 2000 Facebook https://www.facebook.com/groups/jetbrains.gwu/ Twitter https://twitter.com/JetBrains_GWU Email jetbrains.gwu@gmail.com aganezov@gwu.edu