The document outlines an upcoming programming workshop that will cover various JetBrains IDEs like PyCharm, IntelliJ IDEA, and PhpStorm. It then discusses Test Driven Development (TDD), including what TDD is, the development cycle used in TDD, and benefits like encouraging simple designs and confidence. Different types of software tests are also listed like unit tests, integration tests, acceptance tests, and others. Specific testing techniques like unit testing, integration testing using bottom-up and top-down approaches, and acceptance testing are then explained at a high level. Finally, some important notes on testing like trusting tests and prioritizing maintainability are provided.
4. 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
5. 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
6. 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
7. 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
18. 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
19. 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.
20. 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
22. 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.
24. Integration testing
Testing takes place from the
bottom of the control flow
upwards. Components or
systems are substituted by
drivers.
istqbexamcertification.com
25. 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
26. 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
27. 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
29. 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.
32. Important notes
• Trust your tests
• Keep your tests maintainability
• Make your test readabile
33. 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.
34. 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