Keep track of code modifications day after day … and revert to a
previous version if needed
Problem 2
share a developpement between several persons
allow remote accesses from various platforms
quickly find the origin of a Bug in case of regression
Problem 3
How to deal with distributions ?
↪ several versions can coexist (
developpement branches, beta branches, production branches )
Complexity
Several branches to manage simultaneously
…
Or
chrome branches…
A version control system
Acts on a file tree
Allows to pool and share a development
Stores any evolution of the source code
↪ Adds a new dimension to the file
system: time
2 models
centralized
decentralized
Centralized 👹
SVN like
a single reference repository
need of synchronization
need of a server
frequent conflicts …
Decentralized 🔆
several repositories for the same software
everyone can work at their own pace
synchronized or not with others
Advantages of decentralized
systems ⭐️
not dependent on a specific machine
work offline
progressive and “lean” participation in a project
access to the code
proposed contribution
become an active contributor if accepted
main repository
contains the delivered versions of a project
A repository or repo is a central location where
are stored:
file version history
logs
dates, authors, tags, etc.
Repo 📂
A repository appears from the outside as a file system
composed of directories in which we can navigate, read and write
according to the permissions granted.
Master (or Trunck in SVN) 🌳
main version
from it, we can create branches
Branches 🌵
a “secondary” development is initiated
to develop a new feature
to fix a bug
Destiny of a branch
A branch can either be merged again into the “master”
disappear
or give rise to a new program. We speak then of
fork⑂
Checkout
is to get a copy of the existing files in a repository
The result is a working copy
Under git it also consists in choosing his branch (master, dev,
etc.)
Commit ⛳️
git commit -m"added a wonderful new feature"
or if you want to add at the same time all modifications on
existing files :
git commit -am"added a wonderful new feature"
Commit ⛳️
Update local copy and then remote repository
A new revision is created
the working copy must match the last version of the repository
integration test :compute("1 + 2")
returns 3. (See the difference ??)
functional test : if i type 1+2 in
a Web form, and then press the Submit button, i will
get 3 displayed in a green box.
a movie management app unit
test
we make a call to a function searchActor(“bruce”,DB)
where DB is a mockup DataBase created with a unique movie
without any Bruce
it should return null
a movie management app
integration test
if we invoke add(new Film("Star Wars"))
then search movies containing “Star”
we should (at least) get “Star Wars” as result
a movie management app
functional test
On my client home page:
When opening the home page, we see a search bar
we type “Star” and ENTER in this search Bar
We get the list of all Star Wars movies displayed in a green Box
below
Why tests ?
When you code a function, you (almost) always test it, at least
once, at least for one specific input …
but not extensively nor in a rigorous way
launch the program, see what happens on a few inputs
Why are you doing so ?
Why ?
you want to improve bug detection
you want to specify what you expect
when you write the function, you are thinking consciously or not to
some example of function calls.
you are doing unit tests !!
User story
when you ask a client what an app should do, he might start telling
you a story like: “When I come to the home page, I want to connect with
my login and passwd and then consult my tasks for the day, …”
he is describing a functional test
Test Driven Development
if we formalize the idea of thinking first to input/output examples
before coding
we get to the TDD :
define tests
then we code
Obey the testing Goat 🐏
TDD Mantra
TDD steps
Choose an item in the backlog
Create a simple test to check the expected functionnality
Write the test
Launch the test : check that it fails. Commit
!
Write the minimal code to pass the test
Test it. if it’s green, commit !
Refactor
Test the refactoring : launch again the tests. Commit !
Keep going (go back to step 1.) !
demo 2
Let’s start with a backlog of features to implement and focus on unit
tests !
Our Backlog: 2D-Points
Create a Point
get x-coordinate
get y-coordinate
Compare two points for equality
Don’t forget the mantra
TDD cycle
Some tests
def test_point_creation(): p = point(22,7)def test_access_x_and_y():assert22== getx(p)assert7== gety(p)