what is a business requirement?

Posted on by
Reply

Just because the customer asks for something doesn’t make it a requirement.  It makes it a discussion point.  For questions to ask, see my other blog post when should I question a technical business requirement

I tend to see five categories of non business requirements.  Many of these come from posts I’ve seen at JavaRanch rather than my actual users.

1. The customer is making assumptions about the technical implementation
Any requirement starts with an actual need.  Sometimes this is what gets stated as a requirement.  Other times, an implementation is given as the requirement without mention of what the original requirement is.

2. The requirements are technical and suggestions slip in
Some requirements, such as when you are interacting with other systems are technical.  Making it harder to differentiate the actual requirement from implementation suggestions.  With such a technical customer, it’s going to be harder for the customer to separate what is really a requirement in his/her head.  Questions can often draw this out.  And the technical customer may provide more useful insights during this process.

3. The customer  is trying to pre-optimize
Some customers give you requirements based on what they think is easiest rather than what they really want.  This happened to me recently.  My customer asked for something that was acceptable rather than what he preferred because it sounded easier to implement.  (In reality, it was an order of magnitude more work.)  When we talked about it, we decided to go with the actual easier solution.  Talking about it worked out very nicely.

4. The customer doesn’t really know what he/she wants
I think this is the hardest case.  It’s more than asking questions until you find out what is in the customer’s head.  It takes more discussion to help the user figure out what he/she wants.  Often technical mockups/prototypes help.  When you don’t know what you want, you may recognize it when you see it.  Or at least recognize what you don’t like in what you see.

5. The customer isn’t aware of what is out there
Sometimes a customer gives interaction requirements based on the desired behavior.  This makes sense.  At times, this description is extremely similar to an existing widget.  Either a built in one or one that’s already been implemented.  Showing the existing widget often results in something the customer likes better.  (or likes that he/she can get for little effort.)  Of course, technical people don’t always know the name of the widget either as evidenced by my what is this widget called thread!


What other categories can you think of?

writing readable & maintainable tests

Posted on by
Reply

Manning’s Art of Unit Testing is interesting in that it has chapters dedicated to the maintainability and readability of the tests. I didn’t read the whole book as most of it is about unit testing .NET code. (I’m a Java developer)

While these are pretty much all things I do regularly, I learned many of them through experience rather than starting out writing them that way. The most interesting along with some commentary from me were:

Readability

  • name your tests clearly – “test_method_1”, “test_method_2” are not useful names.  Better to say what is being tested.
  • use meaningful asserts – grouping your assertions into those with business meaning makes the main test easier to follow

Maintainability

  • avoid duplicate code – While this should be obvious, developers tend to be better at avoiding duplication in “real” code than “test” code.  It’s all code though.
  • avoid long and hard to understand tests – In my mind, the ideal test is as close to three lines as possible – a setup, a method call and a business assert.  There may be a few more lines.  But if there are too many, it likely the method doesn’t contain enough abstraction.
  • override toString – A great way to see the state of the object when the assert failes.
  • avoid specifying internals for dummy objects – Use stubs where you can.  Unless you are testing the interaction with an interface, you likely don’t need the granularity of mocks.

Anti-patterns

  • constrained test order – Despite the claims of TestNG, tests should remain independent of each other to make them as useful as possible.  It’s nice to see the author from the .NET world leans towards the JUnit philosophy.
  • shared state corruption – static state invites tests to rely on each other
  • multiple tests in same method vs a bunch of asserts for same scenario – I once heard a rule of thumb “one assert per test.”   I think the goal should be one scenario per test instead.  Having a bunch of asserts to check the state of a single logic thing makes sense.  Calling the same method with different parameters is crying out to be different tests.

What are your favorite tips on the topic?

eclipse 3.5 – four good, 1 bad feature

Posted on by
6

I’ve been using Eclipse 3.5 for a couple months now making it a good time to share the features that affected me the most – 4 good; 1 bad.

Getting started

Quick install with favorite plugins:

My Eclipse 3.4 workspace was starting to get corrupted making it a good time to make a clean break.  It wasn’t too time consuming to download/install Eclipse and create a new workspace.  I also installed the plugins I use regularly as I wanted them installed before switching to do development in the new workspace.
Sysdeo – For Tomcat with Eclipse.
Subclipse – For Subversion repository access.  The install of this one leaves something to be desired, but that’s not Eclipse’s fault.  it’s a license thing.
Ecl emma – For code coverage.
PMD – For static analysis.

Workspace setup:

1) Pulling in the source code from SVN is trivial.
2) I tweaked a few settings in the preferences.  I could create an epf file, but I hadn’t changed much in the old workspace.  This was a good opportunity to look at the new preferences in any case.
3) Then there’s the “what I need to do project” – it’s not committed to SVN (which is an accident waiting to happen) – but I have all the information in my gmail account or in my head.  The bulk of that project was a “todo.txt” file which I used to keep track of what tasks I wanted to work on for JavaRanch.  This file is now gone.  Which brings me to my favorite feature #1.

Features

Favorite feature #1 – Task Lists

This feature is awesome!  It replaced my “todo.txt” file for keeping track of stuff. (It’s different than //TODO or //FIXME because it isn’t necessarily tied to code.)  You can specify the status, a due date, categories and estimates.  I’m one of those organized types who likes keeping lists.  At work, I have a piece of paper I write on as I code with little things that come to mind, test cases I need to write, other tasks, etc.  At home, I was using the “todo.txt” file in Eclipse because I have less desk space than at work.  This makes the transition to an actual task list system a natural one and a pleasure.  I also started using gmail’s tasks around the same time.  They serve different purposes.  Eclipse for development.  Gmail for other things.  Did I mention I really like this feature?

Favorite feature #2 – “Open with”

When you use “open type” there is a drop down next to open that lets you choose the “open with” option.  This is really nice.  I can’t count the number of times I’ve tried using open type on a JSP to have it tell me my encryption settings aren’t correct.  I know the solution – open in a text editor – but that wasn’t the default before.  A minor annoyance, but nice to see it resolved.

Favorite feature #3 – Export/import JUnit results

Being able to send an XML file to co-workers about failing tests beats a screenshot.   Especially in terms of seeing the stack trace for “it works on my machine” type bugs.

Favorite feature #4 – Generate toString

This speaks for itself. And easy way to generate toString so it spits out all the fields is a nice time saver.

And the worst feature

Code formatting.  What happened?  This used to work intuitively and well in Eclipse 3.4.  In Java, it gets rid of my careful placed (for readability) whitespace between lines.  I checked the preferences and “number of empty lines to preserve” is set to one.  HTML is much worse.  If I format a bunch of lines containing one <input> per line, Eclipse turns this

<input type="hidden" name="action" value="moveAllSave" />
<input type="hidden" name="module" value="${moduleName}" />
<input type="hidden" name="source_forum_id" value="${sourceForumId}" />
<input type="hidden" name="log_type" value="0" />
<input type="hidden" name="log_description" value="bulk move from admin console">
into this
<input type="hidden" name="action" value="moveAllSave" /> <input
type="hidden" name="module" value="${moduleName}" /> <input
type="hidden" name="source_forum_id" value="${sourceForumId}" /> <input
type="hidden" name="log_type" value="0" /> <input type="hidden"
name="log_description" value="bulk move from admin console">

Huh?  That didn’t happen before.   I tried setting “never join lines” but it doesn’t take effect for HTML. I guess I’m not relying on the code formatting.  Unfortunate as it will slow things down.  But yuck.  Just look at it.