[KyOSS Discuss] Unit Testing / TDD Resources

alan blount alan at zeroasterisk.com
Sat Oct 12 15:12:12 EDT 2013


I agree, I like to test plugins/apis/etc -- but doing so becomes "your
implementation of those 3rd party tools" which is pretty close to testing
"your own code".  Again, that comes down to semantics.

Basically, you can never have too much testing... but it takes time and
effort to build and then to maintain (as specifications/features change you
must also change your tests, which depending on how much testing you have
can be a significant undertaking).

As with everything else, it becomes a balancing act.

Here is a screenshot from our main application (which we are trying to
upgrade now, and fill in holes with unit testing).
http://screencast.com/t/myp3ZrNyIILb

If you notice, there is one section for testing the app, and another
testing our plugins... those are not things we wrote (for the most part)
but they are things we rely on.  Therefore, they should be tested.  Most
have their own tests which we can just run, and a few we may test our
implementations of....

Testing external APIs is tricky, because those APIs can change.  Also
because most APIs don't offer a "development" or "testing" endpoint and you
may not want to submit your real credit card into the codebase for testing,
even if you can void the charge afterward.  There are some reasonable
solutions to this, though.

   - in some cases, you can directly hit the API (eg: s3 storage, make a
   fake container/objects, and then trash)
   - you can still test all API interactions (wrappers) with mocked object
   which fake API interfaces/responses
   - log the real transactions, and ensure they work (statistical analysis)
   - take those "real transaction logs" and ensure they match formatting
   (kind-of a unit-test, well -- not really, but a sanity-test)
   - other ideas?






Thanks,
-alan


On Sat, Oct 12, 2013 at 7:31 AM, Wes Sheldahl <wes.sheldahl at gmail.com>wrote:

> I have to say I strongly disagree with the idea that you should only test
> your own code. The rails framework and other libraries change their apis
> between versions, sometimes in quiet and subtle ways. They change their
> tests at the same time. Rails' tests will not tell you that they removed a
> method between versions.
>
> If you happen to be DHH, you would know that anyway. If not, having tests
> that also cover the parts of your libraries and frameworks that you rely on
> might be worth the cost of slower tests.
>  On Oct 11, 2013 10:34 PM, "Eric Lathrop" <eric at ericlathrop.com> wrote:
>
>> If you have "spotty coverage", then you're not doing TDD. ;-)
>> I'd be happy to sit down and pair with you some night after work.
>> TDD is very much a discipline, and it requires practice.
>>
>> I think the main point from DHH's post is "only test your own code". You
>> shouldn't be testing 3rd party libraries, web frameworks, or your database.
>>
>> Charles Griffin <cegrif01 at gmail.com> wrote:
>>>
>>> Thank you Eric!  Also thank you for pointing out really big ideas that I
>>> almost overlooked yesterday.  The exception thing was huge!  What I'm
>>> wondering is what book would be best suited for testing to really awkward
>>> backend processes where data flows and needs to be correlated.  I have my
>>> way of testing those and it works for the most part, but I feel like I'm
>>> doing "spotty coverage".
>>>
>>> Also I'm interested in hearing your opinion on David Hansson's article
>>> "Testing like the TSA".
>>>
>>> http://37signals.com/svn/posts/3159-testing-like-the-tsa
>>>
>>>
>>> On Wed, Oct 9, 2013 at 11:52 PM, Eric Lathrop <eric at ericlathrop.com>wrote:
>>>
>>>>  I just wanted to pass along some links to good information about
>>>> testing.
>>>>
>>>> Some background on unit testing, and the xUnit pattern that most
>>>> testing frameworks use:
>>>> http://www.martinfowler.com/bliki/Xunit.html
>>>>
>>>> The Art of Unit Testing <http://www.manning.com/osherove/> is a really
>>>> good book to get you started. Although the examples are all .NET, the book
>>>> goes into great detail on all the grey-areas. The author presents good
>>>> rules of thumb, and even talks about how to integrate testing into a team.
>>>>
>>>> Working Effectively with Legacy Code<http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052>discusses how to implement testing on a legacy codebase that currently has
>>>> no tests. It discusses how to break dependencies in an application to make
>>>> testing possible.
>>>>
>>>> Growing Object-Oriented Software Guided by Tests<http://www.growing-object-oriented-software.com/>talks a about how to implement a successful TDD workflow on a large
>>>> project. I haven't read it yet, but it's next on my list, and has been
>>>> recommended to me by multiple people.
>>>>
>>>> _______________________________________________
>>>> KyOSS-Discuss mailing list
>>>> KyOSS-Discuss at kyoss.org
>>>> Subscribe by sending email to kyoss-discuss-subscribe at kyoss.org
>>>> Unsubscribe by sending email (from the address you wish to unsubscribe)
>>>> to kyoss-discuss-unsubscribe at kyoss.org
>>>> Difficulty unsubscribing? Check your email headers for originally-to
>>>> address in case you are forwarding your mail.
>>>> More options at http://kyoss.org/cgi-bin/mailman/listinfo/kyoss-discuss
>>>>
>>>
>>> ------------------------------
>>>
>>> KyOSS-Discuss mailing list
>>> KyOSS-Discuss at kyoss.org
>>> Subscribe by sending email to kyoss-discuss-subscribe at kyoss.org
>>>
>>>
>>> Unsubscribe by sending email (from the address you wish to unsubscribe) to kyoss-discuss-unsubscribe at kyoss.org
>>> Difficulty unsubscribing? Check your email headers for originally-to address in case you are forwarding your mail.
>>>
>>>
>>> More options at http://kyoss.org/cgi-bin/mailman/listinfo/kyoss-discuss
>>>
>>>
>> _______________________________________________
>> KyOSS-Discuss mailing list
>> KyOSS-Discuss at kyoss.org
>> Subscribe by sending email to kyoss-discuss-subscribe at kyoss.org
>> Unsubscribe by sending email (from the address you wish to unsubscribe)
>> to kyoss-discuss-unsubscribe at kyoss.org
>> Difficulty unsubscribing? Check your email headers for originally-to
>> address in case you are forwarding your mail.
>> More options at http://kyoss.org/cgi-bin/mailman/listinfo/kyoss-discuss
>>
>
> _______________________________________________
> KyOSS-Discuss mailing list
> KyOSS-Discuss at kyoss.org
> Subscribe by sending email to kyoss-discuss-subscribe at kyoss.org
> Unsubscribe by sending email (from the address you wish to unsubscribe) to
> kyoss-discuss-unsubscribe at kyoss.org
> Difficulty unsubscribing? Check your email headers for originally-to
> address in case you are forwarding your mail.
> More options at http://kyoss.org/cgi-bin/mailman/listinfo/kyoss-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kyoss.org/pipermail/kyoss-discuss/attachments/20131012/a19f9676/attachment.html>


More information about the KyOSS-Discuss mailing list