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" <[email protected]> wrote:
> Correct. > > > On Mon, Aug 19, 2013 at 11:27 AM, David Gomes <[email protected]>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 <[email protected]> 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" <[email protected]> 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é >>>> <[email protected]>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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]>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 <[email protected]> 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 : [email protected] >>>>>>>>>> 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 : [email protected] >>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >> >> -- >> Mailing list: https://launchpad.net/~elementary-dev-community >> Post to : [email protected] >> 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 : [email protected] > Unsubscribe : https://launchpad.net/~elementary-dev-community > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~elementary-dev-community Post to : [email protected] Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
