https://www.youtube.com/watch?

v=dL08kDGylks&list=PLAwxTw4SYaPkWVHeC_8aSIbSxE_NXI76g&index=160
POgledaj ovo opet

Sta je testiranje:

test inputs ----> sw----> test_outputs ----> if ok then great, if not ok then
debug

Design test inputs and acceptability tests are hard.

Whats going on when we test?

test output---> OK? -----> increased confidence that software is correct

NOT OK? --> we have to discover what is happening
bug in:
system under test
acceptability
specification ----> often learning what to
build
or
bug in OS
compiler
libraries
hardware

Creating sw that can be tested efectively

-clean code
-refactor whenever necessery
-should clearly descibe
-what the module does
-how it interacts with the rest of the system
-no extra threads

-no swamp of global variables

-no pointer soup, soup of refrences

-modules should have unit tests

-when applicable support for fault injection

-assertions, assertions, assertions

Assertions
*Assertions are not for error handling
*Never make assertions with side effects
*No silly assertions

Trust boundry
If you dont trust the users to not cross a boundary,
then we have to test functions so we test the full domain under test and output
range

Ljudi su losi u testiranju ovih interfejsa u svim input domenima.

GUI: domain (set of all possible gui actions clicks, keyboard, events, swipes)
---> GUI application states

What are good tests for a GUI?

Defensive coding

Issuing calls on libraries and virtual machines

test the web browser by

Timing dependant problems

Splay tree example:

Fuzzing

Random testing of a bounded queue:

Well-understood API +small code +strong assertions + mature+

tuned random tester+ good coverage results= confidence

Building a test suite

This is ran during nights for example

Goal is to show that all have passed

1. A lot of unit tests, feature specific tests

2. Large realistic inputs

3. Regression tests, any input that has caused so the software fails on a
bug that we already fixed.

4. random tester # ovo ljudi zaboravljaju i ostavljaju kao zasebni problem

Hard testing problem:

What can make testing really hard?

lack of specification
no comparable implementations
big Software under test
large highly structured input space
non determinism
lots of hidden state
Summary of testing principles:
________________________________________________
Testers must want software to fail

testers are detectives:

they must be observant for suspicious behaviour and anomalies in the SUT
all available test oracles should be used in testing

test cases should contain values selected from entire input domain

interfaces that cross a trust boundary need to be tested with represntable value,
not just those
from the ostensible inout domain

a little brute force goes a long ways:

1. sometimes, selected interfaces can be exhaustively tested

2. almost everything else can be randomly tested

Quality cannot be tested into bad software

no hidden coupling, side channels
few variables exposed to concurrent processes
few global variables shared between modules
no pointer soup

Code should be self checking, whenever possible using lots of assertions:

these assertions are not used for error-checking
assertions must never be side effecting
assertions should never be trivial or silly

when appropriate all three kinds of input should be used as a basis for testing:
apis that are provided by the SUT
apis used by the sut can be tested using fault injections
non functional inputs
____________________________________________________________

Todo:

implementirati testove web aplikacije slicno reddit-u:

https://www.youtube.com/watch?v=WARkqLBreoQ&ab_channel=Udacity

https://www.youtube.com/watch?v=pklED4UfODg&ab_channel=Udacity