addressalign-toparrow-leftarrow-leftarrow-right-10x10arrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcredit-cardcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobe--smallglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1languagelaunch-new-window--smalllight-bulblightning-boltlinklocation-pinlockm-swarmSearchmailmediummessagesminusmobilemoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstar-shapestartickettrashtriangle-downtriangle-uptwitteruserwarningyahooyoutube

Re: [mysql-144] Re: [TriPUG] Tripug: PHP Best Practices

From: Michael K.
Sent on: Monday, August 16, 2010, 10:56 PM
Also just found:
https://news.ycomb...­
and
https://www.wausit...­


On Mon, Aug 16, 2010 at 9:46 PM, Michael Kimsal <[address removed]> wrote:
> I would still be of the 'test first' persuasion. ?The writing of the
> tests is part of the process of defining the specifications.
>
> I'm also someone who mixes 'unit' tests with 'functional' or
> 'integration' tests. ?I don't think having dependencies on database
> structures and such is necessarily bad. ?From a practical perspective
> the process needs to be repeatable for each run of the test. ?Test
> data representing the various aspects of your app's data needs is
> invaluable.
>
> On Mon, Aug 16, 2010 at 9:40 PM, Neal Anders <[address removed]> wrote:
>> As I am just beginning down the road of a large project that consists of
>> mostly completely new code (some of it based on existing functionality and
>> some of it greenfield) I'm struggling with the right approach to developing
>> unit tests.. specifically for the brand new functionality that might be
>> covering uncharted territory and have only loosely defined specifications or
>> user stories or test cases.
>>
>> For the 'porting' of existing functionality there is at least some derived
>> structure and examples of what should go in, what should come out, and what
>> validates a test.
>>
>> In the case of brand new functionality, where the development of the code
>> may evolve via trial and error and over time until the right approach or
>> implementation is achieved, where opportunities for optimization and
>> re-factoring may occur, I'm hesitant to also carry the burden of re-writing
>> the unit tests that would go along with such a liquid part of the code base.
>>
>> There are some who would say:? Write your unit test first and then code.
>>
>> And some who might prefer to write tests as you code.
>>
>> I'm wondering if it's ever ok to write your code, then your test case.
>>
>> ..and if there are certain indicators of if'/when one approach is better
>> over another?
>>
>> Neal
>> ____________________­____________
>> From: Steve W. <[address removed]>
>> To: [address removed]
>> Sent: Mon, August 16,[masked]:39:27 PM
>> Subject: Re: [mysql-144] Re: [TriPUG] Tripug: PHP Best Practices
>>
>> There seems to be some debate on using PHPUnit for Unit testing and
>> Functional Testing.
>> PHPUnit looks interesting and there are some fine addons - like
>> coverage testing for larger projects.
>>
>>
>>
>> On Mon, Aug 16, 2010 at 12:23 PM, Michael Kimsal <[address removed]> wrote:
>>> Some other 'best practices' (or perhaps just 'good practices').
>>>
>>>
>>> 1. ?Write unit and functional tests.
>>> 2. ?As Bryan said, use meaningful variable names.
>>> 3. ?Adopt a style and use it consistently (I still struggle with this a
>>> bit).
>>> 4. ?Use tabs, not spaces :)
>>> 5. ?Use phpdoc on your methods and functions.
>>>
>>> Any others you all want to contribute?
>>>
>>
>>
>>
>>
>> --
>> Please Note: If you hit "REPLY", your message will be sent to everyone on
>> this mailing list ([address removed])
>> https://www.meetup...­
>> This message was sent by Steve W. ([address removed]) from The Raleigh
>> MySQL/PHP Meetup Group.
>> To learn more about Steve W., visit his/her member profile:
>> https://www.meetup...­
>> To unsubscribe or to update your mailing list settings, click here:
>> https://www.meetup...­
>> Meetup, PO Box 4668 #37895 New York, New York[masked] |
>> [address removed]
>>
>>
>>
>>
>>
>> --
>> Please Note: If you hit "REPLY", your message will be sent to everyone on
>> this mailing list ([address removed])
>> This message was sent by Neal Anders ([address removed]) from The
>> Raleigh MySQL/PHP Meetup Group.
>> To learn more about Neal Anders, visit his/her member profile
>> To unsubscribe or to update your mailing list settings, click here
>>
>> Meetup, PO Box 4668 #37895 New York, New York[masked] |
>> [address removed]
>
>
>
> --
> Michael Kimsal
> https://jsmag.com­ - for javascript developers
> https://groovymag....­ - for groovy developers
> https://indieconf....­ - web freelancer conference
>[masked]
>
>
>
> --
> Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
> https://www.meetup...­
> This message was sent by Michael Kimsal ([address removed]) from The Raleigh MySQL/PHP Meetup Group.
> To learn more about Michael Kimsal, visit his/her member profile: https://www.meetup...­
> To unsubscribe or to update your mailing list settings, click here: https://www.meetup...­
> Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]
>
>



-- 
Michael Kimsal
https://jsmag.com­ - for javascript developers
https://groovymag....­ - for groovy developers
https://indieconf....­ - web freelancer conference
[masked]

People in this
group are also in: