Some weeks ago I tried to write acceptance tests for the web application I’m developing at Allbus srl.
We test all the server, but none of us have ever tested the client before. I tried Selenium IDE, a Firefox extension, but the generated code was totally useless. A test must talk only about what you want to test: “grid has toolbar” or “picking a date will reload this combo”. Tests should not talk about secondary stuff. You are not testing that div#ext-comp-1001 has a toolbar, who cares of that id? That grid has that id today, but when you will add other components to the page, the test will not work anymore.
Continue reading →
This post is not titled “why git”, so I won’t talk about its incredible speed, the concept of distributed repository, or the absence of fifthy thousands “.svn” folders everywhere in your filesystem.
I just want to explain what makes it really different from other VCS.
Think about snapshots, not revisions
The first trauma I had when I saw for the first time a git repository was the absence of natural, understandable integer numbers in the revisions.
Coming from Subversion I had myfile.php at revision 1, then revision 2, and so on. And you can clearly understand that revision 1532 is newer than revision 14.
Well, git does not think about versions, but about snapshots. Every time you commit, git saves a snapshot of your files and stores it (this is where the weird hash comes from). This is the same way you would do by hand: create some files, create a tar of your working directory, do some changes, create a new tar. The difference is that git will include in the snapshot only changed files, so it won’t waste space.
If you want to know more about the internal git workflow, read Pro Git.
