testing, uml and brokerage

Hello,

I am about to embark on my first project utilizing unit testing and I
have a couple of questions if anyone would be so kind to enlighten me.

1. In reference to uml how does it relate to XP and unit testing. I am
assuming since XP is more of a development procedure and uml a planning
procedure, that they are unrelated. Perhaps uml use cases can help
identify tests to build?

2. In the past I have always built a 'broker' namespace that
facilitates the building of objects and enforces biz rules. This way
code that creates objects is seperated from class code. Does this go
against XP and unit testing?

3. I understand that XP is not only unit testing, but I am the only
developer in house and am trying to digest this in managable chunks

After developing apps for about 2 years without XP I find my apps are
not of the quality I would like them to be hopefully unit testing and
XP can help me in this sense

Thank you!

dkode wrote:

> 1. In reference to uml how does it relate to XP and unit testing. I am
> assuming since XP is more of a development procedure and uml a planning
> procedure, that they are unrelated. Perhaps uml use cases can help
> identify tests to build?

UML is not a methodology.

What have you read about XP? Under Test Driven Development, you ask the
Onsite Customer what the next feature is, and then you write simple test
cases for that feature. You follow each test with passing code, and as the
design grows you refactor it.

This "emergent design" is a good goal, yet other systems can easily
augment it, such as planning the design of a module. Just make sure, when
you implement, that you always s ways to remove lines - even if you
planned them! - and see if all the tests pass. Tests are a way to prove
your design is as simple as it can get.

> 2. In the past I have always built a 'broker' namespace that facilitates
> the building of objects and enforces biz rules. This way code that creates
> objects is seperated from class code. Does this go against XP and unit
> testing?

How could it?

In theory, if your customer requests business rules, you may eventually
find the simplest refactor is a module that brokers them. If not, then you
learn how simple you can get.

> 3. I understand that XP is not only unit testing, but I am the only
> developer in house and am trying to digest this in managable chunks

Remember to create a new release - even just an internal one - once a
w. That way you won't put off details, like install scripts, that could
bite your butt later.

> After developing apps for about 2 years without XP I find my apps are not
> of the quality I would like them to be hopefully unit testing and XP can
> help me in this sense

Dude, you are so ready to just start writing the tests! Read any book with
TDD on the cover and then start doing it. Report back here about the
results. You should find you need to debug much, much less often.

--
Phlip

Philip,

Thanks for the advice. I will definately post back how development is
going.

One question I had is what did you mean by internal releases once a
w and install scripts. Almost all apps I create are web based, so
maybe your comment only applies to exe's

Thankf again for the comments!

Phlip wrote:
> dkode wrote:
> 
>
> UML is not a methodology.
>
> What have you read about XP? Under Test Driven Development, you ask the
> Onsite Customer what the next feature is, and then you write simple test
> cases for that feature. You follow each test with passing code, and as the
> design grows you refactor it.
>
> This "emergent design" is a good goal, yet other systems can easily
> augment it, such as planning the design of a module. Just make sure, when
> you implement, that you always s ways to remove lines - even if you
> planned them! - and see if all the tests pass. Tests are a way to prove
> your design is as simple as it can get.
> 
>
> How could it?
>
> In theory, if your customer requests business rules, you may eventually
> find the simplest refactor is a module that brokers them. If not, then you
> learn how simple you can get.
> 
>
> Remember to create a new release - even just an internal one - once a
> w. That way you won't put off details, like install scripts, that could
> bite your butt later.
> 
>
> Dude, you are so ready to just start writing the tests! Read any book with
> TDD on the cover and then start doing it. Report back here about the
> results. You should find you need to debug much, much less often.
>
> --
>   Phlip

dkode wrote:

> One question I had is what did you mean by internal releases once a
> w and install scripts. Almost all apps I create are web based, so
> maybe your comment only applies to exe's

What have you read about XP?

How could web apps be exempt from install scripting?

How do you deploy to the target server? By uploading the files you remember
modifying?

That situation seems to show a great need for install scripts!

About frequent releases: A team should firm-up a release candidate, once a
w. The decision to release that candidate to users should then be a
business decision.

After they approve a candidate, you can't just say, "Oh, now we have to
manually copy the files to the server, and dick around with live database
tables," and so on. You can't have any hidden surprise or cost. So, once a
w, you should run install scripts that upload your web site to a test
server. Then automated scripts (using Watir, for example) should probe that
server with acceptance tests.

So the "frequent release" rule implies you must maintain your entire system,
not just your source code. Each Friday you demo the program, and its new
features, to a business representative. If they approve the release, you run
your scripts again, targetting the production server. Then you spot-check
the result, and go home, assured that you won't have any surprises.
Releasing to the production server is just a variation on releasing to a
test server, and you do that so often that your install scripts are robust
and bulletproof.

--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!