Basic conceptos about Software Testing.

1. Testing Basic
Concepts
by Iván Corrales Solera, @wesovi

2. Index
● Code with tests vs code w/o tests
● Tests oriented development
● Types of testing
● Frameworks and tools (Java apps)
● Tests automation and CI
● Testing examples

3. Code with tests or w/o tests
● Do you think is better to do tests in your developments?
○ I supposed your answer would be YES
● Do you think development process take longer if we do tests?
○ YES? Why?
○ No, You are right, but why?
● What are the benefits of doing testing?
○ ….
Brief questions

4. Code with or w/o tests
Code with TestsCode w/o Tests
Refactor is so
risky!
Just necessary code
Software
with unused
code
Tests are our best documentation
We need to
get in the code
Developers Spending time
on understanding what code
does
Life is easier for new developers
Quick bug-fixing
Quality Software
Spending
long time on
bug-fixing
compiled
code but
NOT
software..
Re-factor is safe

5. Tests oriented development
Start writing tests
See the tests fail
Write code to make the tests pass
Pass the tests

6. TDD
● We will write code to make tests work
instead of writing some tests to check part of
our code.
● High test coberture levels.
● If we need to do bug-fixing we will start
writing some tests before making changes in
the code.
● Developers with experience in that
programming language.

7. BDD
● No technical people can define our tests
or help us to write them at least.
● Both technical and non technical people
speak the same language.
● BDD doesn’t mean not to do unit
testing.
● Our user stories will be completed when
acceptance criterias are satisfied.
● User stories can be tracked in the code.

8. Comparison
Steps
1. We have the software requirements
2. We think about what we need to test
3. We write some tests
4. Tests will fail
5. We write code to pass the tests
6. We can do some re-factor
Pros
● Code with quality
● We do not have unnecessary code
● We ensure our software works as expected.
● High test coberture level
● Low Bug-fixing time
Steps
1. We have the software requirements
2. We write code for the requirements
3. We write some tests to check our software
work
4. Run the tests
5. We’ll be happy when we have a test that
pass (probably because we know the
result before writing it)
Pros
● We have code with some tests
● Some coberture level
● Highly probably software with no high
quality
Writing code before tests Test before coding

9. Types of testing
Unit Testing
Integration Testing
Acceptance Testing
Stress Testing
UI Testing
Monkey Testing
Load Testing ….. Testing, Testing, Testing
Plenty types of testing… BUT we only need to do those testings that contribute to ensure the
quality of our application

10. Tests oriented development
People not used to
do test
Just code but NOT Software
Maybe Over tested
applications...
Software with QA and correct tests
No tests
We do not apply the correct
testing
Identify which testing are
suitable for our application
Code with lack of Testing

11. Tips on Testing
Do tests but just those ones that have sense for your code
Identify what kind of testing should we do depending on the application
Practicing TDD or NOT is up to the developers. They should never be forced to do it
Enforce developers to do tests but do NOT establish a minimum test coberture

12. Unit Testing
What are the unit testing for?
● Ensure a piece of code or method works as expected
● Make us achieve high test coberture levels
● Easy for developers but not understable by non-technical people.
● Tests must be run without application deployments
● Mocks are required
When do not we have to do unit testing?
● Front end applications
● We use MDA
● We use kind of code generation
frameworks.
When should we do unit testing?
● Complexed methods
● Algorithms and mathematics calculus

13. Integration Testing
When do not we have to do integration
testing?
● Our application does only one basic thing
such as a math operation or display hello
world in the screen.
When should we do integration testing?
● Most of architectures: WS, Batch,
microservices ,...
● Backend developed in Javascript (e2e)
● User interfaces
What are the integration testing for?
● Ensure our system works as expected.
● Does not really guarantee a high test coberture level.
● They must be run in environment similar to the production one.
● We could be forced to use mocks in case of we interact with third-party systems.

14. Acceptance Testing
What are the acceptance testing for?
● Make technical and non technical people speak the same language
● In scrum these tests would be the acceptance criterias defined for the user stories.
● If these are not defined by the Product Owner, we need his/her validation at least.Some people
think these tests are unnecessary since integration testing could be enough. (And they could be
right indeed)
● Natural language syntax (When, Then, And…. ) See below an example:
Given 10 can of beers
When I drink 2 of them
Then I should have 8 in my fridge.

15. Frameworks and tools (Java apps)

16. Tests automation and CI
Compile & Build Unit Tests Integration Tests Acceptance Tests
● The above flow represents the steps in the ci process.
● Each step above would be a different job in Jenkins (or whichever other CI tool)
● Each step will generate a report with the results
● We should not move to the next step in the flow in case of there were tests failing
● Developers must be able to run the tests from their local environment.

17. Sample - e2e for nodejs REST API
Code: https://github.com/wesovi/nodejs-authentication-api
Technologies: Nodejs, mocha, supertest
Snippet:
it('should response BAD REQUEST & the error details when password is empty ', function (done) {
var credentials = {username:"email@mail.com"};
request(app)
.post('/accounts/authenticate')
.send(credentials)
.set('Content-Type', 'application/json')
.expect('Content-Type', 'application/json; charset=utf-8')
.expect(400)
.expect({errors:[{ param: 'password', msg: 'required' }]})
.end(done);
});