elementary-dev-community team mailing list archive

[Alex Lourie <djay.il@xxxxxxxxx>]

Right.

1. The code tests another piece of code.
2. You specify it with a set of 'trial' inputs.
  a) you expect the 'correct' inputs to work correctly.
  b) you expect the 'incorrect' inputs to fail gracefully.


On Mon, Aug 19, 2013 at 12:07 PM, A. "Xylon" V. <avlabs314@xxxxxxxxx> wrote:

> So if I understand correctly, in TDD there is a specific bit of code (lets
> call it C) that you build a test for. Then, instead of using the
> application and trying to trigger code C, you invoke the test which
> directly calls code C and then reports a result based on whatever input you
> gave it, right?
> On Aug 19, 2013 9:43 AM, "Alex Lourie" <djay.il@xxxxxxxxx> wrote:
>
>> Correct.
>>
>>
>> On Mon, Aug 19, 2013 at 11:27 AM, David Gomes <david@xxxxxxxxxxxxxxxx>wrote:
>>
>>> So say this code for example:
>>>
>>>
>>> http://bazaar.launchpad.net/~elementary-apps/pantheon-terminal/trunk/view/head:/src/TerminalWidget.vala#L37
>>>
>>> Sometimes we have some issues with ReGex (see
>>> https://code.launchpad.net/~voldyman/pantheon-terminal/colon-fixed/+merge/180735
>>> ).
>>>
>>> Is that the kind of thing we can use TDD for? Like have a bunch of URLs
>>> and see if Terminal detects them or not without any GUI, just terminal
>>> Found/Not Found messages?
>>>
>>> ~David "Munchor" Gomes
>>>
>>>
>>> On Mon, Aug 19, 2013 at 1:38 AM, Craig <weberc2@xxxxxxxxx> wrote:
>>>
>>>> David,
>>>>
>>>> I understand and appreciate the difficulty; however, I've had exactly
>>>> zero questions about TDD. Like I said in the original post, I'm happy to
>>>> answer any questions you may have.
>>>>
>>>> Please take me up on that offer any time.
>>>>
>>>> Thanks,
>>>> Craig
>>>> On Aug 18, 2013 6:57 PM, "David Gomes" <david@xxxxxxxxxxxxxxxx> wrote:
>>>>
>>>>> This, this and this.
>>>>>
>>>>> And also many of the developers like me aren't really experienced with
>>>>> TDD and will have to take some time to study, learn and adapt to it. You
>>>>> can't just come here and tell developers, many of whom inexperienced young
>>>>> amateur programmers, to start using TDDs. Take me, for example, I never had
>>>>> proper programming education, I'm 17 years old. I know what TDD is but I've
>>>>> never used it before. You have to understand TDD is something very
>>>>> enterprise-ish and "professional" that "big serious" companies do.
>>>>>
>>>>> Look, I'm not saying we can't do it or we shouldn't do it or we won't
>>>>> do it - I'm just saying you need a better approach to what you're doing. I
>>>>> realize how useful and important TDD can be, but many of us might just be
>>>>> too busy having fun.
>>>>>
>>>>> Regards,
>>>>> David
>>>>>
>>>>> PS. I really hope I wasn't rude, I mean all I said in the nicest of
>>>>> ways.
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Aug 18, 2013 at 11:58 PM, Daniel Foré <daniel@xxxxxxxxxxxxxxxx
>>>>> > wrote:
>>>>>
>>>>>> This all sounds great and I think everybody is pro-testing, however
>>>>>> I've yet to see a reproduce-able example or a guide regarding any kind of
>>>>>> tests being implemented (especially by those extremely vocal about their
>>>>>> importance). Not books or articles about why testing is good, but something
>>>>>> that actually shows a person how to write tests for their apps.
>>>>>>
>>>>>> So, as Linus would say, "Talk is cheap. Show me the code."
>>>>>> —
>>>>>> Sent from Mailbox <https://www.dropbox.com/mailbox> for iPhone
>>>>>>
>>>>>>
>>>>>> On Sun, Aug 18, 2013 at 3:47 PM, Craig <weberc2@xxxxxxxxx> wrote:
>>>>>>
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>> tl;dr: Unit tests are pretty much necessary to have an architecture
>>>>>>> on which you can run automatic system-level tests, and if you aren't
>>>>>>> automating then testing becomes too impractical.
>>>>>>>
>>>>>>> When you describe "system tests" you are actually describing what
>>>>>>> are called "acceptance tests" or "behavioral" tests (
>>>>>>> http://www.extremeprogramming.org/rules/functionaltests.html). Unit
>>>>>>> tests test small units of code such as classes or functions. Traditional
>>>>>>> TDD relies primarily upon unit tests, and those are primarily what I'm
>>>>>>> referring to.
>>>>>>>
>>>>>>> One of the primary purposes of unit testing is to ensure good code
>>>>>>> architecture. If you don't unit test, you probably won't have good access
>>>>>>> points for your acceptance tests (how do you verify that that Gtk.Label has
>>>>>>> the correct text when you can only access the top level window?), so
>>>>>>> automation will be out of the question. And if you aren't automating then
>>>>>>> you can't continuously integrate (running all tests every time a change is
>>>>>>> made to the repository in order to find bugs as soon as they are made).
>>>>>>> Honestly, if you aren't automating then testing becomes too impractical.
>>>>>>> On Aug 18, 2013 5:10 PM, "Alex Lourie" <djay.il@xxxxxxxxx> wrote:
>>>>>>>
>>>>>>>> Hi Craig
>>>>>>>>
>>>>>>>> For the clarification purposes, I'd like to separate 'automatic
>>>>>>>> tests (system testst)' and 'unittests'. I consider them different things.
>>>>>>>> Unittests are pieces of code that test some other pieces of the code.
>>>>>>>> System tests are scripts/code/steps that test that your program (or part of
>>>>>>>> it) works. Unittests are usually run automatically (by, say, unittesting
>>>>>>>> framework). System tests could be run automatically or manually. There are,
>>>>>>>> sometimes, frameworks for that, but in most cases it's either manual or
>>>>>>>> custom developed.
>>>>>>>>
>>>>>>>> Unittests are (usually) developed by the same developer who
>>>>>>>> developed the original code, just as in your TDD example. System tests are
>>>>>>>> best developed by external party (such as users).
>>>>>>>>
>>>>>>>> From here on, I can agree with you on point 1, and the naming.
>>>>>>>>
>>>>>>>> Basically, we all agree that having *testing *is a good practice
>>>>>>>> and a feasible way to manage the complexity of software. But unittesting
>>>>>>>> cannot test the logical connections between the blocks of code in the
>>>>>>>> program. That's the job for system testing.
>>>>>>>>
>>>>>>>> I don't care how we call it. The more *systematic *testing we do
>>>>>>>> for Elementary the better it's going to be, and the more chances we have to
>>>>>>>> sustain growth.
>>>>>>>>
>>>>>>>> So I would just like to see testing implemented. Any kind of it.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Aug 18, 2013 at 10:56 PM, Craig <weberc2@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>> Hi Alex,
>>>>>>>>>
>>>>>>>>> To correct you on a couple of things:
>>>>>>>>>
>>>>>>>>> 1. TDD **does not** require you to have all or even several of the
>>>>>>>>> tests written before hand. It simply requires you to have the test written
>>>>>>>>> for the next change you are about to make. The idea is to write a test, run
>>>>>>>>> the test to watch it fail (this helps verify you wrote your test
>>>>>>>>> correctly), add the simplest code to make the test pass, run the test to
>>>>>>>>> watch it pass (and verify your code additions worked). Then you rinse and
>>>>>>>>> repeat.
>>>>>>>>>
>>>>>>>>> 2. TDD is actually a simplified form of what developers do
>>>>>>>>> already. That is, you usually write some code, run your code, then visually
>>>>>>>>> verify that it worked. TDD just crystalizes this process in code which can
>>>>>>>>> be executed later. TDD isn't hard, so it's well within the capacity of all
>>>>>>>>> of our devs; however, it does taking some getting used to. TDD is the best
>>>>>>>>> and fastest way to develop quality code and it's the ONLY practical way to
>>>>>>>>> raise the ceiling on the amount of code complexity a team of a given size
>>>>>>>>> can handle (there is a lot of research and professional heuristics about
>>>>>>>>> this). If a developer doesn't have the will to do this, they aren't taking
>>>>>>>>> their discipline seriously and, frankly, are a danger to any project that
>>>>>>>>> values quality. Besides, I've never met a developer who has hit the
>>>>>>>>> complexity ceiling *and* who has practiced TDD who doesn't advocate this
>>>>>>>>> kind of testing.
>>>>>>>>>
>>>>>>>>> With those corrections in mind, I can't see any difference between
>>>>>>>>> your first point and "real TDD". I agree that your 2nd point is a good
>>>>>>>>> idea. Automated testing can't capture everything, and it's definitely
>>>>>>>>> important to have some hands-on testing that we could run through a few
>>>>>>>>> times every release. But we should always be working toward automated
>>>>>>>>> testing so developers can, you know, develop.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Aug 18, 2013 at 2:05 PM, Alex Lourie <djay.il@xxxxxxxxx>wrote:
>>>>>>>>>
>>>>>>>>>> Ok, I have not added a single line of code to elementary yet, and
>>>>>>>>>> gave some decent amount of headache to real devs around here. I have though
>>>>>>>>>> participated in development of many products, small and large, and so here
>>>>>>>>>> it goes.
>>>>>>>>>>
>>>>>>>>>> TDD in its pure form requires having tests written and ready
>>>>>>>>>> before the code is written. Then failing tests are being implemented one by
>>>>>>>>>> one, having the code both tested and working in the end of this process. I
>>>>>>>>>> highly doubt that any of Elementary devs have the capacity or the will to
>>>>>>>>>> follow this. Especially, when many of our projects are built using 'try and
>>>>>>>>>> error' methodology, that is they follow the 'Hey! Let's try this!' rule.
>>>>>>>>>> Which is awesome, as it allows fast development and really quick release
>>>>>>>>>> cycles.
>>>>>>>>>>
>>>>>>>>>> Now, what I think would fit Elementary much better is simply
>>>>>>>>>> testing (yes, that QA thing everyone loves and adores) - the T from TDD,
>>>>>>>>>> which is the most important part. The best way to do that is, of course, to
>>>>>>>>>> create a bunch of automatic tests, but that's not really feasible either.
>>>>>>>>>> So as I see it, we can do 2 things:
>>>>>>>>>>
>>>>>>>>>> 1. Start looking into unittesting as much and as early as
>>>>>>>>>> possible, and have devs starting to create tests. This has the benefit of
>>>>>>>>>> devs learning to create unittests and having some of the code tested, and
>>>>>>>>>> also, potentially, at some point, it could help moving to real TDD.
>>>>>>>>>> 2. Start creating manual test procedures for basic staff. Yes, it
>>>>>>>>>> requires a lot of human power and time, but also do translations. This is
>>>>>>>>>> the most boring part of software engineering, but it is the one that can
>>>>>>>>>> bring balance to the force. Also, some of these can sometimes be automated
>>>>>>>>>> too, so it's not all that aweful.
>>>>>>>>>>
>>>>>>>>>> I personally think we need both 1 and 2. I am a strong believer
>>>>>>>>>> in testing as means to improve the product. But TDD is probably an
>>>>>>>>>> overshoot in our case. We need to start with *something*, and right now we
>>>>>>>>>> don't really have it.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Aug 18, 2013 at 8:41 PM, Craig <weberc2@xxxxxxxxx> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> I posted the following message on Google Plus yesterday, but it
>>>>>>>>>>> occurred to me that the weekend may not be prime time for checking that
>>>>>>>>>>> social network. I think this message is pretty important, so I want to post
>>>>>>>>>>> it again here: (I apologize in advance for its length)
>>>>>>>>>>>
>>>>>>>>>>> Congratulations to all the developers who made Luna such a
>>>>>>>>>>>> success!  You've done a great job and delivered an incredible Linux
>>>>>>>>>>>> experience!
>>>>>>>>>>>>
>>>>>>>>>>>> I know I bring this up periodically, but I'm concerned that
>>>>>>>>>>>> Luna + 1 and future releases will take more and more time to release,
>>>>>>>>>>>> and/or that you will quickly reach a ceiling with respect to the amount of
>>>>>>>>>>>> code we'll be able to maintain before quality degrades.
>>>>>>>>>>>>
>>>>>>>>>>>> The cause for my concern is the nature of complexity: as
>>>>>>>>>>>> software grows (that is, as code is added), bugs grow exponentially
>>>>>>>>>>>> (complexity increases exponentially with logic, and bugs grow linearly with
>>>>>>>>>>>> complexity). If we don't start working toward solutions that will scale
>>>>>>>>>>>> with this problem, we **will** hit a ceiling with respect to the amount of
>>>>>>>>>>>> complexity we will be able to support (this means fewer features or
>>>>>>>>>>>> less-powerful features). I promise.
>>>>>>>>>>>>
>>>>>>>>>>>> I know some in the community are working toward this goal, but
>>>>>>>>>>>> I think it's going to take a concerted effort on the part of the developers
>>>>>>>>>>>> to take this problem seriously. I urge you all to take this problem as
>>>>>>>>>>>> seriously as you take the rest of the user experience (because bugs are, at
>>>>>>>>>>>> the end of the day, a sharp degradation of the user experience).
>>>>>>>>>>>>
>>>>>>>>>>>> In my experience, the silver bullet for combating this problem
>>>>>>>>>>>> is test driven development. If you look around the software development
>>>>>>>>>>>> industry, code is improving, and it's largely because TDD is catching on.
>>>>>>>>>>>> And Google is a good role model in this regard (not just for us, but for
>>>>>>>>>>>> everyone--they are pioneers of code quality). If you're a developer and
>>>>>>>>>>>> you're unfamiliar with TDD, take some time and research it. It will pay
>>>>>>>>>>>> dividends immediately. If you have any questions about development, I'm
>>>>>>>>>>>> happy to provide my advice as a professional developer. Also, read up on
>>>>>>>>>>>> Google's testing strategies (I recommend
>>>>>>>>>>>> http://www.amazon.com/Google-Tests-Software-James-Whittaker/dp/0321803027_How Google Tests Software_).
>>>>>>>>>>>>
>>>>>>>>>>>> You guys are a _great_ UX shop, now let's become a great code
>>>>>>>>>>>> shop. I hope this analogy doesn't offend anyone who is passionate about
>>>>>>>>>>>> their tech brands, but my advice is this:
>>>>>>>>>>>>
>>>>>>>>>>>> Design like Apple, develop like Google.
>>>>>>>>>>>>
>>>>>>>>>>>> I really push you developers to continue to strive to hone your
>>>>>>>>>>>> craft the way Daniel and Cassidy (and any other UX designers) are learning
>>>>>>>>>>>> to hone theirs.
>>>>>>>>>>>>
>>>>>>>>>>>> P.S., Sorry for the book, and I hope you all take this as
>>>>>>>>>>>> respectful, constructive criticism. _Please_ ask me anything about
>>>>>>>>>>>> development, especially with respect to how we can keep quality high using
>>>>>>>>>>>> processes rather than sheer developer effort (so as to free you developers
>>>>>>>>>>>> to work on interesting problems rather than bug hunting).
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for reading,
>>>>>>>>>>>> Craig
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>
>>>
>>
>>
>> --
>> 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
>>
>>


-- 
Alex Lourie