elementary-dev-community team mailing list archive
Mailing list archive
Re: Congratulations Luna developers!
Guys, Here is a conversation I and Craig had a while ago. The mail was
dispatched to Craig's personal inbox by mistake.
Here it is
I have read the book "*How google tests softwares*" and not to say that TDD
is a great tool to hit on both productivity and maintenance but I
personally think that the major problem for Elementary community is not the
knowledge of programming tactics or lack of efforts but that *Vala *dont
really have any capable TDD suite.
All you can do is to write tests and run them manually or with cmake (I
dont have any idea how all the cmake wizardry works) which adds up another
overhead for test maintenance. Because there is no real test suite for Vala
(and we dont have test ethics either) people will tend to write tests in
whatever way they can make it work and push it upstream, and the problem
arise when someone else picks up the project and have absolutely no idea
what the test does.
So, If the community is really passionate about TDD a potential solution
what I can come up with is, we set a guideline for tests in same way we
have *HIG* and *Code Guidelines* and put together some *cmake* thingy which
can be used to automate the testing process *OR* start hitting up this
project that Yorba has adopted, here
I dont have any idea about Valadate, I came across it randomly one day
Generally speaking, I agree with this. To clarify on a few points however...
1.* I don't think testing overhead or the lack of standard test framework
are reasons not to test, but obstacles to be overcome as we start
implementing tests.* (in other words, even if we were missing a testing
framework, we still should automate our tests). That said, we should get
the Elementary project template setup so a user need only add his/her test
files into the /test/CMakeLists.txt file just like they have to do now with
/src/. From there, we can just use whichever testing framework seems best
(we can use GLib's testing framework if no others seem good).
2. I definitely agree that testing should make it into the Code Guidelines.
While this perspective may not be appropriate for an open source project,
but in my projects (at work) I advocate rejecting code that doesn't have
corresponding tests or code for which the accompanying tests are
inadequate. It seems extreme, but it reflects an uncompromising focus on
quality, which seems in line with Elementary's ethos.