headers
Charlie Poole | 6 May 2013 20:33
Picon
Gravatar

ANN: NUnitLite 0.9 Release

Hi All,

I'm announcing the release of NUnitLite 0.9 today.

In case you were not aware, NUnitLite has surprised me by attracting a
lot of users who previously used full-on NUnit. I originally intended it
for
use on platforms with limited resources, but it turns out that the
simplicity
of a test framework is appealing in other contexts as well.

Here are some of the major changes in the 0.9 release:

Framework

* A .NET 4.5 build is included. When using the 4.5 package,
  C# 5.0 async methods may be used as tests, as the target of
  a Throws constraint and as an ActualValueDelegate returning
  the value to be tested.

* Experimental builds for Silverlight 3.0, 4.0 and 5.0 are included.

* TestContext.Random may be used to provide random values of various
  types for use in your tests.

* The experimental Asynchronous attribute has been removed.

Runner

* The runner now supports the -include and -exclude options, which
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Carter | 6 May 2013 04:10
Favicon

[Summary] If you could get your colleagues to read just one book on TDD, which would it be?

Test Driven Development by Example (Kent Beck) + 4
GOOS + 2
Refactoring + 2
Working Effectively With Legacy Code + 2
Clean Code + 1
The Mikado Method (mikadomethod.org)
RSpec
Agile Software Development, Principles, Patterns, and Practices
Effective Unit Testing
Refactoring to patterns by Josh Kerievsky.
Osherov, The Art of Unit testing
jbrains, Responsible Design for Android - on going work, somewhat builds on
GOOS
The Agile Samurai
The Art of Agile Development.
Test Driven Development for Embedded C

Test Driven Development for Embedded C is probably the one to go for if
your problem is "How Can we Do this Stuff in C"?

The TDD by example has the most votes... partly I suspect because it is one
of the oldest.

I suspect GOOS and Responsible Design for Android have some updated ideas
in them.

I really really really like The Mikado Method <http://mikadomethod.org>

It isn't about Unit Testing... but I suspect (no, I know) it works very
well with Working Effectively With Legacy Code
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Carter | 1 May 2013 01:30
Favicon

What I hate about *Unit frameworks.

Most of them invest way too much effort to make up for the deficiencies of
the Windows Operating system.

The Component in a Computer tasked with managing concurrency, task
separation, and ensuring full clean setup and tear down is....

The Operating System.

So if you want to be dead, 100% sure that this test doesn't corrupt that
test... you use a process.

Nope, not try / catch, not exception handling. That's a flaky almost
solution.

One test === One Process.

Each process is an address space that appears.... and vanishes.

But, but, but Processes Are HeavyWeight you can't create and run thousands
of processes!

Oh yes you can.

Processes are lightweight under Unix and have been for decades.

In fact much of the hype about threads is a result of Microsoft marketing
spin to cope with the fact that Windows 3.1 processes were incredibly
heavyweight kludges.

In fact there are relatively few places where one should use threads when
(Continue reading)

Permalink | Reply | 19 comments |
headers
John Carter | 30 Apr 2013 05:12
Favicon

If you could get your colleagues to read just one book on TDD, which would it be?

Conversely, which books would you expect a TDD master to have read?

-- 
John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                       Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch       Email : john.carter <at> taitradio.com
New Zealand

-- 

------------------------------
This email, including any attachments, is only for the intended recipient. 
It is subject to copyright, is confidential and may be the subject of legal 
or other privilege, none of which is waived or lost by reason of this 
transmission.
If you are not an intended recipient, you may not use, disseminate, 
distribute or reproduce such email, any attachments, or any part thereof. 
If you have received a message in error, please notify the sender 
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or 
corrupted during transmission nor can we guarantee that any email or any 
attachments are free from computer viruses or other conditions which may 
damage or interfere with recipient data, hardware or software. The 
recipient relies upon its own procedures and assumes all risk of use and of 
opening any attachments.
------------------------------

[Non-text portions of this message have been removed]

------------------------------------
(Continue reading)

Permalink | Reply | 16 comments |
headers
Charlie Poole | 20 Apr 2013 07:41
Picon
Gravatar

Erroneous Assertion about TDD

Hi All,

Here's an excerpt from a newsletter I got from O'Reilly today...

"For many old-school software engineers, *developing code* has always been *as
much an art as a science*. But as the industry focuses more on practices
such as Test-Driven Development, and Patterns become the lingua franca of
programming, *is there any room left for real creativity in coding?* Or,
has it become an exercise in cookie-cutter production, putting together
components in new ways, but without any real room for individual style?"

How can such misunderstanding can still exist? Anyway, they asked for
opinions and I sent this:

"I was a bit dismayed at your question "...as the industry focuses more on
practices such as Test-Driven Development, and Patterns become the lingua
franca of programming, is there any room left for real creativity in
coding?"

"I'll address the point as it applies to Test-Driven Development, since
that's closest to my heart. I'm an advocate of TDD as well as the
maintainer of NUnit, a unit-test framework that aims to facilitate TDD.

"To put it baldly, anyone who finds that Test-Driven Development stifles
their creativity simply isn't doing TDD as it's intended to be practiced.
The self-imposed discipline of first discovering tests that will require
the development of the production code we actually want to write is without
a doubt difficult to learn. But once it is learned, it's a source of great
creativity. Just as the strict form of the sonnet allowed Shakespeare to
channel his creativity, the discipline of TDD demands creativity from
(Continue reading)

Permalink | Reply | 3 comments |
headers
haewke | 17 Apr 2013 06:38
Picon

Implementation of game tree search using TDD

Hi,
I am trying to use TDD to implement game tree searching but I am running
into some issues.Using C#, MS Test  and Rhino Mocks.
My requirement is to traverse a tree to a specified depth and find the
maximum value of the nodes at this depth. If a path ends before the
specified depth then the value of the last node in the path should be
considered.
Sample usage looks like this:
var depth = 5;
var tree = new GameTree();
var treeSearch = new TreeSearch();var maxValue =
treeSearch.FindMaxValue(tree, depth);
I started with the following tests:

    * A search to depth zero should return the value of the root node
    * A search to depth one with no children should return the value of
the root node
    * A search to depth one with one child should return the value of the
child
    * A search to depth one with two children should return the highest
value of the two children
    * A search to depth one of a tree with depth two should return the
maximum value at depth one
Up to this point the tests are simple enough and mocking of the tree is
simple. The last test starts driving towards a depth first tree
traversal.Now I start on depth 2 tests which should drive the rest of
the tree traversal algorithm:
    * A search to depth two should return the maximum value at depth two
I decided to mock a complete binary tree with depth 2. The test looks
like this:        public void
(Continue reading)

Permalink | Reply | 7 comments |
headers
rakesh mailgroups | 2 Apr 2013 16:53
Picon

Testing business rules and not deploying the entire stack

Hi,

I'm building a new system and I want to get it 'right'.

What does right mean? It means I want to test my business rules against
just Java classes.

This approach has been advocated by Uncle Bob (I believe) and is very
seductive because I have worked on many projects where eventually, due to
running on a full stack, the test suite begins to slow down drastically.

The approach seems to be to express your business requirements in a
non-infrastructure related way. I can just about see this with a web app
with a html front end. Instead of saying 'click button Add User', you could
say 'select Add User' and call the underlying service call that the
controller was going to.

(You still don't know if the button works of course, but you could have a
few, full stack tests to make sure).

This approach has some disadvantages though. The main one being you cannot
always separate the business requirements and the infrastructure.

A classic example is a RESTful web service. The business requirements are
full of GET, POST, DELETE, PUT, urls, application media types and JSON
payloads. Writing requirements in this language makes sense to everybody
involved including public consumers of the service and to abstract away the
http infrastructure seems wrong.

Of course, once I start running my tests against a deployed web app, I am
(Continue reading)

Permalink | Reply | 7 comments |
headers
Alan Baljeu | 28 Mar 2013 14:13
Picon
Favicon

!!!


http://www.san-gregorio-de-polanco.com/bmeueps/zzwdi.tjuh?az  

 
3/28/2013 2:13:55 PM

3/28/2013 2:13:55 PM                                                                       

[Non-text portions of this message have been removed]

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    testdrivendevelopment-digest <at> yahoogroups.com 
    testdrivendevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roy Osherove | 19 Mar 2013 13:33
Favicon
Gravatar

ANN: My TDD Master Class is Available online (not free)

Hi Folks.
I hope you find this class useful - it is recorded live in my five days TDD
master class. focus is on .NET, but Java and C++ devs will find it helpful
as well.

the cost is about half the ticket to a normal class, with about 10 hours of
video demos and talks. based on my book "The Art of Unit Testing"

I have created 20 coupons for use in this mailing list: use coupon code
"tddlist" to get the course at $350 instead of $500 .
https://www.udemy.com/tdd-in-net-with-roy-osherove/

--

-- 
Thanks,

Roy Osherove

   -  <at> RoyOsherove
   - Author of "The Art Of Unit
Testing"<https://www.udemy.com/tdd-in-net-with-roy-osherove/>
http://ArtOfUnitTesting.com )
   - My blog for team leaders: http://5Whys.com
   - My favorite keyboard shortcuts: http://key.bo
   - +972-524-655388 (GMT+2)

[Non-text portions of this message have been removed]

------------------------------------

Yahoo! Groups Links
(Continue reading)

Permalink | Reply | 0 comments |
headers
johantoutsimplement | 19 Feb 2013 22:23
Picon
Gravatar

Kata for test smells

Hi everyone,

I've been asked to teach test smells Thursday (!) and I'm looking for a piece of test code that has a good
number of them in order to use it for identifying and then removing the test smells. I plan to make the
learners work on their proper test code but I'd like them to warm up on one or two "distilled" examples
first. And I'm thinking someone has already done that before and might have it lying around somewhere.

I did find the introduction example in Meszaros book "xUnit Test Patterns" which could do. But I was hoping
for some choice.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    testdrivendevelopment-digest <at> yahoogroups.com 
    testdrivendevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 6 comments |
headers
Amir Kolsky | 17 Feb 2013 15:00
Picon
Favicon

RE: How do you write tests if you aren't sure what the result should be?

OK, that makes it even simpler. 

This is where TDD can tell you whether you've reached your final destination
or not. You can calculate the exact point where the penguin should stop "in
the real world", and then specify what the allowed error is.

At this point you need to refine your algorithm, taking into account things
like the current framework, current location, elapsed time, etc. until the
test passes.

A.

-----Original Message-----
From: testdrivendevelopment <at> yahoogroups.com
[mailto:testdrivendevelopment <at> yahoogroups.com] On Behalf Of Avi Kessner
Sent: Sunday, February 17, 2013 1:03 AM
To: testdrivendevelopment <at> yahoogroups.com
Subject: RE: [TDD] How do you write tests if you aren't sure what the result
should be?

My comparison was supposed to be regarding the culmative calculation,  not
the per tick calculation.

Ill have to look up when velocity is multiplied vs when it's added.
On Feb 17, 2013 3:46 AM, "Amir Kolsky" <kolsky <at> actcom.net.il> wrote:

> **
>
>
> I may be missing something about this whole discussion, but isn't the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane