On Jul 19, 2012, at 4:48 PM, Piotr Praczyk wrote: > Hello ! > >> From: Samuele Kaplun >> >> Hi Piotr, >> >> In data mercoledì, 18 luglio 2012 11.10:23, Piotr Praczyk ha scritto: >>> It is less related to the failing tests themselves, but if the mechanisms of >>> testing as quality measure of the software does not work, it does not >>> motivate to write new regression/unit tests. >> >> On the other hand some people prefer to follow the test-driven-development, >> by >> first implementing tests for functionalities that not yet exists so that they >> will be eventually implemented as originally designed. YMMV. > > Up to now, my understanding of test-driven development was slightly different > and I did not even think about such approach.
What I noticed is that we always test our code when coding. The problem is that test is manual. By taking the time to automate it, you get your time back very fast since you are basically running tests all day: adding some coding then testing, adding some code, testing etc. > I always though about writing tests for currently implemented feature and > satisfying them before a commit. > I think, the weakness of this approach lies in the size of a team that is > collaborating on a project. > If You have small number of frequently communicating developers, this can > work. > If everyone starts uploading failing tests, all other developers have to deal > with them and see results (which results in issues described in previous > e-mail). > It is very difficult to distinguish tests that should fail because things are > not implemented from these that fail because something is broken. > Moreover, commiting failing tests carries a risk of commiting tests which > will never succeed because they are simply not well written (This is the case > with at least one currently commited test). > This also leads to trouble. > Maybe it is better to use task tracking system for new features or at least > mark tests as not-satisfied, so that testing framefowk could distinguish them > automatically ? > I guess having a separate repository for tests of future features (one branch > related with one ticket) is a bit of an overkill on the side of > infrastructure, but we could think about something better than now. > I am using nose as a wrapper around unittests. nose has a way of skipping tests. Check http://nose.readthedocs.org/en/latest/plugins/skip.html We could have a similar concept so that we know which tests are supposed to fail and they do not bother us unless we want to. -- Alessio Deiana INSPIRE Developer GS-SIS-OA CERN
smime.p7s
Description: S/MIME cryptographic signature
