keeping details straight when composing

[mathetes333]

Hey folks, new to the list and thought I would try to enlist some of your knowledge and wisdom.

How do you, when composing the tests, not lose track of the details
and keep the tests from becoming fragile.

I'm having a hard time following the one assert per test
and then after having several of them, I start to lose
the details complex flow/coordination of what is suppose
to be going on.

Sometimes I don't even know all the tests ahead of time.
I almost think I want to write some sort of integration
test first.

Anyhow, thanks in Advance.

[Olof Bjarnason]

2009/9/1 mathetes333 <mathetes333@...>:

>
>
> Hey folks, new to the list and thought I would try to enlist some of your
> knowledge and wisdom.
>
> How do you, when composing the tests, not lose track of the details
> and keep the tests from becoming fragile.
>
> I'm having a hard time following the one assert per test
> and then after having several of them, I start to lose
> the details complex flow/coordination of what is suppose
> to be going on.
>
> Sometimes I don't even know all the tests ahead of time.
> I almost think I want to write some sort of integration
> test first.

Write the integration test first, then "go down" and fill in the
smaller, more focused unit tests.

Then, when you have finished the unittests, the integration tests
should become green too.

When I start using multiple asserts per test, I try to refactor the
setup-logic to a separate method, or use the unit testing frameworks
facilities for that behaviour ([SetUp]-attribute in NUnit for
example). Then, each test case will have that logic "for free" (no
duplication) and it is more viable to write one assert in each test
method.


Instead of:

test
  setup-fiddling
  assert1
  assert2

.. refactor to:

setup:
  setup-fiddling

test1:
  setup()
  assert1

test2:
  setup()
  assert2


>
> Anyhow, thanks in Advance.
>
>



--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

[franz see]

In addition, you may also rethink about your original 'unit'. It may have
started simple, but it may have grown into something more complex, thus you
may have to break it down. For example, if what you want to assert is too
implementation specific but not really intrinsic to the basic idea of your
SUT, then you may opt to extract that to another method/class, and test
that.

On Wed, Sep 9, 2009 at 6:24 AM, Olof Bjarnason <olof.bjarnason@...>wrote:

>
>
> 2009/9/1 mathetes333 <mathetes333@... <mathetes333%40yahoo.com>>:
>
> >
> >
> > Hey folks, new to the list and thought I would try to enlist some of your
> > knowledge and wisdom.
> >
> > How do you, when composing the tests, not lose track of the details
> > and keep the tests from becoming fragile.
> >
> > I'm having a hard time following the one assert per test
> > and then after having several of them, I start to lose
> > the details complex flow/coordination of what is suppose
> > to be going on.
> >
> > Sometimes I don't even know all the tests ahead of time.
> > I almost think I want to write some sort of integration
> > test first.
>
> Write the integration test first, then "go down" and fill in the
> smaller, more focused unit tests.
>
> Then, when you have finished the unittests, the integration tests
> should become green too.
>
> When I start using multiple asserts per test, I try to refactor the
> setup-logic to a separate method, or use the unit testing frameworks
> facilities for that behaviour ([SetUp]-attribute in NUnit for
> example). Then, each test case will have that logic "for free" (no
> duplication) and it is more viable to write one assert in each test
> method.
>
> Instead of:
>
> test
> setup-fiddling
> assert1
> assert2
>
> .. refactor to:
>
> setup:
> setup-fiddling
>
> test1:
> setup()
> assert1
>
> test2:
> setup()
> assert2
>
> >
> > Anyhow, thanks in Advance.
> >
> >
>
> --
> twitter.com/olofb
> olofb.wordpress.com
> olofb.wordpress.com/tag/english
>  
>

--
Franz Allan Valencia See | Java Software Engineer
franz.see@...
LinkedIn: http://www.linkedin.com/in/franzsee


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

[Омельченко Геннадий]

Hi!

 

It's not necessary follow one assertion per test literally, you can just use
custom assertion utils as described in xUnit Test Patterns. Thereby, you can
end up both obvious tests and complex assertion.

Also, you should try top-down approach, It can help a lot

  _____  

Hey folks, new to the list and thought I would try to enlist some of your
knowledge and wisdom.

How do you, when composing the tests, not lose track of the details
and keep the tests from becoming fragile.

I'm having a hard time following the one assert per test
and then after having several of them, I start to lose
the details complex flow/coordination of what is suppose
to be going on.

Sometimes I don't even know all the tests ahead of time.
I almost think I want to write some sort of integration
test first.

Anyhow, thanks in Advance.



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

[Adrian Howard]

On 1 Sep 2009, at 17:34, mathetes333 wrote:

> I'm having a hard time following the one assert per test
> and then after having several of them, I start to lose
> the details complex flow/coordination of what is suppose
> to be going on.

Can you give some examples of the kind of test that you're writing? If  
you're losing track of the details it might be that you're taking to  
large steps - and need to TDD in smaller test/code/refactor cycles

> Sometimes I don't even know all the tests ahead of time.
> I almost think I want to write some sort of integration
> test first.

Why do you need to know all of the tests ahead of time?

Cheers,

Adrian

--
http://quietstars.com  -  twitter.com/adrianh  -  delicious.com/adrianh