elementary-dev-community team mailing list archive

[Jaap Broekhuizen <jaapz.b@xxxxxxxxx>]

You can do that using behaviour driven testing tools. For example in python
webdevelopment I use pytest and pytest-bdd in combination with splinter and
Firefox.

--
Jaap
Op 21 aug. 2013 22:49 schreef "A. "Xylon" V." <avlabs314@xxxxxxxxx> het
volgende:

> Thanks guys, another noob question, how do we write tests for GUIs? Like
> give different inputs to a dialog, or to an entry?
> On Aug 21, 2013 9:46 PM, "Jaap Broekhuizen" <jaapz.b@xxxxxxxxx> wrote:
>
>> The whole point of test driven development is tot write tests for
>> functionality that does not exist, and then implement the functionality
>> based on that test. You just write tests for the functionality you are
>> going tot build, and use them as a blueprint for the actual implementation.
>>
>> --
>> Jaap
>> Op 21 aug. 2013 22:38 schreef "A. "Xylon" V." <avlabs314@xxxxxxxxx> het
>> volgende:
>>
>>> Ermm, another quick question, how do we write tests for code which
>>> hasn't been written yet? Are we supposed to magically predict bugs or what
>>> features another developer might add?
>>> On Aug 21, 2013 9:35 PM, "Kurt Smolderen" <kurt.smolderen@xxxxxxxxx>
>>> wrote:
>>>
>>>>
>>>> This might be one point of view to look at it, but let me try to
>>>> explain another. Most of the time I'm a Java and C++ developer. I've been
>>>> experimenting with Vala a few times, of which many of them was actually
>>>> about hunting bugs in existing programs not written by myself. When
>>>> programming in Java, I almost always write tests before actually writing
>>>> the main code. The reason for this is twofold:
>>>>
>>>>    1. My personal experience is that it actually lead to a better
>>>>    design as you are forced to think in small chunks of code (the code must be
>>>>    testable)
>>>>     2. Java has the tools to make writing tests (and run them) very
>>>>    easy. JUnit and others are well integrated in IDEs such as Eclipse,
>>>>    Netbeans, IntelliJ and others.
>>>>
>>>> Now let's go back to the bug-hunting stuff. As a Java developer, I
>>>> sometimes had to hunt for bugs in programs written by others. Although I
>>>> was unfamiliar in almost all the cases with the actual code, it was more
>>>> easy to find bugs in code which had tests written for it, compared to the
>>>> code which did not include tests. The reason: the code was often much more
>>>> structured when tests were written and from the tests it was more easy to
>>>> 'guess' the initial developer 'intentions'.
>>>>
>>>> The reason I'm sharing this is that I actually do not believe that
>>>> writing tests will drive new contributors away, but might be a way of
>>>> attracting them as their initial 'confrontation' with Elementary code might
>>>> be more successful. They stumble upon a bug and decide to have a look at
>>>> the code. As Vala is currently missing a decent IDE (such as Eclipse,...)
>>>> and debugging isn't as easy due to the fact the code is translated into C,
>>>> its often very difficult to analyse the flow of a program. Available tests
>>>> might help this initial contributors with analysing the existing code and
>>>> actually find (and fix) the bug they were hunting.
>>>>
>>>> Of course this story also proves that even when people write tests, bug
>>>> occurs. And in many cases, bugs occur due to the fact that test are not
>>>> 100% correct (for example, they do not sufficiently tests special cases).
>>>> But at the same time, if the new contributor wants his code to work, he
>>>> probably will adjust the existing tests as well and hence improve the
>>>> overall test-quality of the program.
>>>>
>>>> So in order to conclude: I really think tests might be a way to make it
>>>> easier for new contributors to succeed in their willingness to get involved
>>>> into the elementary project. However, some things need to be kept in mind:
>>>> (1) Vala is currently not that well supported in IDEs which makes it more
>>>> difficult for Java/ C#/ C(++) developers to get into it and (2) tools need
>>>> to be available which make it easy to write and execute the tests.
>>>>
>>>> Kind regards
>>>> Kurt
>>>>
>>>> On 21-08-13 18:15, Julien wrote:
>>>>
>>>> So if I'm not mistaken, TDD requires you to write tests *before*implementing something.
>>>>
>>>>  This might work well for teams with enough developers that don't have
>>>> to rely on volunteers and drive-by contributors, but I don't see this
>>>> working out for elementary, at least not at this point.
>>>>
>>>>  Many contributors fix a few small bugs here and there and don't have
>>>> much experience with development, which is why we try to keep the entry
>>>> barrier really low for new devs. When I started here, I had no experience
>>>> with Vala, Gtk and Launchpad at all, and I just fixed some easy bugs,
>>>> implemented some small features in various apps and so on.
>>>>
>>>>  If we used TDD, we would have to reject most code by new devs,
>>>> because they didn't implement tests, and then we'll have to explain to them
>>>> how to use tests, and then they'll have to write tests, but that's bad
>>>> because you have to write them before you write the actual code ...
>>>>
>>>>  It's going to be a mess.
>>>>
>>>>  What might work are regular unit tests, implemented by people who
>>>> kind of know what they're doing (we need some documentation for that, maybe
>>>> add it to the dev guide). This will give us some of the TDD benefits w/o
>>>> deterring potential new devs.
>>>>
>>>> On Wed, Aug 21, 2013 at 3:29 PM, Craig <weberc2@xxxxxxxxx><weberc2@xxxxxxxxx>wrote:
>>>>
>>>>
>>>> I have never heard a project die because they decided to move to TDD.
>>>>> And I heard about lots of hits on the matter.
>>>>
>>>>
>>>>  This. I've heard (and witnessed) a lot of projects drop their defect
>>>> percentage from 20% to 3%.  A lot of new-to-TDD developers don't like it at
>>>> first because it feels slower, but I don't think those people remember how
>>>> much time is spent bug hunting at the end of a release cycle.
>>>>
>>>>  I think the next step is to find a pilot project and get the lead
>>>> developer(s) to agree to work toward TDD. This will probably look like:
>>>>
>>>>  1) Modifying the project structure to include _test directories
>>>>  2) Creating tests with GLib.Test or some such
>>>>  3) Coaching/mentoring the developers at TDD
>>>>  4) Performing code reviews in which insufficiently tested code is
>>>> sent back for revision
>>>>
>>>> After testing it out for a few months, the community can see how they
>>>> like it.
>>>>
>>>> Does this sound like a reasonable approach? If so, would any project
>>>> leads like to volunteer their project? And who in the community would like
>>>> to participate in such an experiment?
>>>>
>>>>
>>>> On Wed, Aug 21, 2013 at 4:34 AM, Alex Lourie <djay.il@xxxxxxxxx> wrote:
>>>>
>>>>> Albert
>>>>>
>>>>>  We don't need to exaggerate. Though TDD is, indeed, a development
>>>>> methodology, it is not supposed to completely change the way everyone works.
>>>>>
>>>>>  Just consider that writing a good test takes about 10 minutes, and
>>>>> that each developer writes one or two tests for new stuff they add (or the
>>>>> old one they fix) from time to time. Then, in time, you'll have part of
>>>>> your code tested, which is exactly what we're aiming for. Beginning is
>>>>> hard, continue something is easier.
>>>>>
>>>>>  I have never heard a project die because they decided to move to
>>>>> TDD. And I heard about lots of hits on the matter.
>>>>>
>>>>>
>>>>>  On Tue, Aug 20, 2013 at 3:37 AM, Albert Palacios <optimisme@xxxxxxxxx
>>>>> > wrote:
>>>>>
>>>>>> Hi Craig,
>>>>>>
>>>>>>  Thanks for your explanation and the linked video. I am still
>>>>>> agnostic, but I don't want to be the only one who complained about the
>>>>>> proposal.
>>>>>>
>>>>>>  At this point I have more questions than answers, and those will
>>>>>> probably be solved with a working example.
>>>>>>
>>>>>>  But remember, *TDD is a development methodology* not a testing
>>>>>> methodology. It will change our development work flow, and will probably
>>>>>> move potential volunteers away from the project.
>>>>>>
>>>>>>  TDD like every other development methodology does not fit every
>>>>>> project or team. It can be a hit, and it can even the death of the project.
>>>>>>
>>>>>>  Albert
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 20, 2013 at 12:50 AM, Craig <weberc2@xxxxxxxxx> wrote:
>>>>>>
>>>>>>> Hi Albert,
>>>>>>>
>>>>>>>  Thanks for your response, you asked a lot of great questions. In
>>>>>>> addition to Gufran's earlier response.
>>>>>>>
>>>>>>>   Can you prove that there will be huge benefits in time/resources?
>>>>>>>
>>>>>>>
>>>>>>>  Well, that depends on what you consider "proof". In the spring, my
>>>>>>> company paid several thousand dollars to send me to a conference in San
>>>>>>> Jose in which many software development authorities recited, "test driven
>>>>>>> development pays itself off in iteration 0". That means the very first time
>>>>>>> you write the code it has already paid for itself (because even before you
>>>>>>> get the automatic-regression testing benefits, you've already got the
>>>>>>> benefits of a better architecture and documentation--because the tests
>>>>>>> _are_ the documentation!). I'm sure I can dig up lots of other resources,
>>>>>>> but I think it should suffice to say that I've never heard an expert
>>>>>>> comment on TDD except to say it's fastest way to develop quality software.
>>>>>>> For more information addressing your specific concerns, see the Wikipedia
>>>>>>> article's "benefits" section (and read on to the "shortcomings" as it is
>>>>>>> also relevant:
>>>>>>> http://en.wikipedia.org/wiki/Test-driven_development#Benefits. Even
>>>>>>> more importantly, this short video:
>>>>>>> http://www.youtube.com/watch?v=DodJQyHsmHI
>>>>>>>
>>>>>>>
>>>>>>>  Can you prove that there will be less bugs? (looks like that if
>>>>>>>> tests are not right, bugs will populate equally).
>>>>>>>
>>>>>>>  It's pretty hard to write bad tests if you're practicing TDD,
>>>>>>> because you write the test first, watch it fail, insert the code you need
>>>>>>> to make it pass, and then hopefully watch it pass. If you wrote a bad test,
>>>>>>> it very probably will pass before you've written the code to make it pass
>>>>>>> (which serves to alert the programmer that his test is bad or his software
>>>>>>> is doing something unexpected) or the test will fail after he has correctly
>>>>>>> written the next line of code (which serves to alert the programmer to
>>>>>>> review both the code and his test and identify the source of the problem).
>>>>>>> For this reason alone, many, many bugs are eliminated.
>>>>>>>
>>>>>>>  From what's been said, looks like there will be an extra effort on
>>>>>>>> development, adding complexity and more tools to know (not to say maintain).
>>>>>>>
>>>>>>>  Besides the initial learning curve, development actually goes
>>>>>>> _faster_ with TDD (see the aforementioned Wikipedia article--I can provide
>>>>>>> more resources on demand) because debugging time becomes exponentially more
>>>>>>> expensive as time passes after the bug has been introduced. This is because
>>>>>>> the bug can live anywhere in any code that has been added *since the last
>>>>>>> time the tests were run* and because the programmer will have an
>>>>>>> increasingly difficult time remembering the code he wrote at the time of
>>>>>>> the bug as time progresses. With TDD, you are running the tests after every
>>>>>>> change (generally you test every time you build), so as soon as you've
>>>>>>> broken something you find out about it. This means that the bug is
>>>>>>> guaranteed to live in the last change you made, which is a smaller sample
>>>>>>> and fresher-in-your-mind than changes you made weeks ago. Regarding your
>>>>>>> complexity concern, generally the process isn't complex (it's actually very
>>>>>>> simple) and it _simplifies_ development once you learn how to do it. The
>>>>>>> most complex part is figuring out how to integrate testing into the CMake
>>>>>>> project, and that's only complicated because CMake is complicated.
>>>>>>> Regarding tools, there are already testing tools available for Vala,
>>>>>>> including GLib (so we don't have to maintain anything). Anyway, testing
>>>>>>> tools don't take a terribly long time to learn.
>>>>>>>
>>>>>>>   Can we focus on the half done things before adding new projects?
>>>>>>>> Granite is not ready, documentation is missing, not to talk about the bugs
>>>>>>>> that survived Luna release ...
>>>>>>>
>>>>>>>
>>>>>>>  TDD is more valuable the sooner you start implementing it. Even if
>>>>>>> you didn't write tests for old code and only started TDD with new code (and
>>>>>>> existing defects), you would be doing yourself a huge favor. I'm not
>>>>>>> suggesting that everyone stop what they're doing and go back and test every
>>>>>>> line of code (although it would be a good thing to chip away at over time),
>>>>>>> but practicing TDD on _new_ code can't hurt that much, can it?
>>>>>>>
>>>>>>> With that in mind, are there any arguments against TDD that outweigh
>>>>>>> its merits?
>>>>>>>
>>>>>>> Thanks again for your questions! :)
>>>>>>> Craig
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 19, 2013 at 12:32 PM, Albert Palacios <
>>>>>>> optimisme@xxxxxxxxx> wrote:
>>>>>>>
>>>>>>>> Hi Craig and Gufran,
>>>>>>>>
>>>>>>>>  I don't agree with TDD, and making a committee. Can you prove
>>>>>>>> that there will be huge benefits in time/resources? Can you prove that
>>>>>>>> there will be less bugs? (looks like that if tests are not right, bugs will
>>>>>>>> populate equally). Can you prove that creating, modifying and fixing code
>>>>>>>> is going to be easier?
>>>>>>>>
>>>>>>>>  From what's been said, looks like there will be an extra effort
>>>>>>>> on development, adding complexity and more tools to know (not to say
>>>>>>>> maintain).  Can we focus on the half done things before adding new
>>>>>>>> projects? Granite is not ready, documentation is missing, not to talk about
>>>>>>>> the bugs that survived Luna release ...
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Aug 19, 2013 at 7:27 PM, Gufran <dogabhai@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>> Count me in.
>>>>>>>>> I cant really put forward any point on how should we proceed but
>>>>>>>>> I'd definitely love to be with the team.
>>>>>>>>> Yes, a *testing committee* is a good idea, maybe something
>>>>>>>>> independent of dev community. We can write scripts to automate tests, and
>>>>>>>>> we can do that in any language (Python for example), so it would be like a
>>>>>>>>> Python coupling between software and tests.
>>>>>>>>> Just my two cents :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Aug 19, 2013 at 10:43 PM, Craig <weberc2@xxxxxxxxx> wrote:
>>>>>>>>>
>>>>>>>>>>  This is cool and important, but I don't think it should stop
>>>>>>>>>> the discussion on test driven development. Perhaps this could be a separate
>>>>>>>>>> thread? It doesn't sound as though anyone is opposed to TDD, so can we
>>>>>>>>>> confirm that? And if no one is opposed, how can we proceed? Can we start
>>>>>>>>>> some kind of a "testing committee" to help determine what testing steps are
>>>>>>>>>> needed, what framework to use, and how to integrate testing into the
>>>>>>>>>> existing project structure (i.e., using CMake)?
>>>>>>>>>>
>>>>>>>>>>  Does this sound like a good plan? Thoughts?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Aug 19, 2013 at 12:05 PM, David Gomes <
>>>>>>>>>> david@xxxxxxxxxxxxxxxx> wrote:
>>>>>>>>>>
>>>>>>>>>>> I'll work on it, so far we only have this I made:
>>>>>>>>>>> https://dl.dropboxusercontent.com/u/19899464/reviewstutorial.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Aug 19, 2013 at 6:01 PM, Albert Palacios <
>>>>>>>>>>> optimisme@xxxxxxxxx> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Munchor,
>>>>>>>>>>>>
>>>>>>>>>>>>  A contribution / bug fixing step by step guide is needed at
>>>>>>>>>>>> the developers site. There was a .pdf before the new site change, but now
>>>>>>>>>>>> it is impossible to find.
>>>>>>>>>>>>
>>>>>>>>>>>>  The problem with the old guide is that it encouraged to
>>>>>>>>>>>> create your own branch instead of using the ~elementary-dev-community one
>>>>>>>>>>>> (this is totally new for me). Obviously, bazaar guides doesn't teach you on
>>>>>>>>>>>> using the "elementary-dev-community".
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Aug 19, 2013 at 6:57 PM, David Gomes <
>>>>>>>>>>>> david@xxxxxxxxxxxxxxxx> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>  I always tell people if they make their branches owned by
>>>>>>>>>>>>> ~elementary-dev-community I will volunteer to fix the code style myself. I
>>>>>>>>>>>>> have all the free time and the will to do it, just people always make their
>>>>>>>>>>>>> branches owned by themselves.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  ~David "Munchor" Gomes
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  On Mon, Aug 19, 2013 at 4:29 PM, Albert Palacios Jimenez <
>>>>>>>>>>>>> optimisme@xxxxxxxxx> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>  Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Before talking about testing, and advanced development
>>>>>>>>>>>>>> techniques for teams with resources, there is one easy and simple thing we
>>>>>>>>>>>>>> can do to accelerate development.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sometimes (very often), bugs are stopped due spaces not
>>>>>>>>>>>>>> following the "code style" guidelines. Adding a "code style" validator
>>>>>>>>>>>>>> script before compiling, we can prevent uploads with spaces at the end of
>>>>>>>>>>>>>> the lines ...  and save a lot of time.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For example, just executing the next line before compiling:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> find . -type f -print0 | xargs -0 sed -i 's/[ \t]*$//'
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We will remove every "white space" at the end of any line,
>>>>>>>>>>>>>> including new lines with tab spaces.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This can sound stupid, but it is absurd to block bug fixes
>>>>>>>>>>>>>> during several days due white spaces at the end of lines.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>>>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>>  Alex Lourie
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>> --
>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>