Foysal | 8 Oct 2009 05:49
Picon
Favicon

Multiple method or different class for a ComboBox loading?

Hello everyone. I am new in this group. I use layer architecture in my
work. I am in a situation described below:
DAO: Company (Company object: has Id and Name)DAL: CompanyGateway
(Queries are handled in here)BLL: CompanyManager (Business logics are
checked in here)UI: CompanyUI (User Interface)
I have a combo in UI which loads company names into it. Generally, we
write a GetAllCompanies() method in CompanyGateway class. But sometimes
we need to fetch different data for different combo in a project. So, we
need to write different methods for each DAO objects in separate Gateway
classes.
But if i want to create a method ( LoadCombo() )in a separate class (
suppose: ComboLoader.cs)  where i will give the table name or other
specific parameters and the method's only responsibility is to return a
data table for loading the combo, how it sounds?
I am giving the code snippet for your better understanding. I am using
C# as the language.
========================================================================\
=========
         public DataTable ComboLoader(string tableName)        {
string selectQuery = "SELECT * FROM [" + tableName + "]";           
SqlDataAdapter adapter=new
SqlDataAdapter(selectQuery,DBConnector.SqlConnectionObj);           
DataTable dataTable=new DataTable();            try            {
DBConnector.OpenSqlConneciton();                adapter.Fill(dataTable);
}            catch (Exception exception)            {
throw new Exception("Data could not retrived from database.",exception);
}            finally            {               
DBConnector.CloseSqlConnection();            }            return
dataTable;        }
========================================================================\
(Continue reading)

Richard | 9 Oct 2009 23:43
Favicon
Gravatar

Agile Code Reviews, Part 2


	In my post on agile code reviews, I described how we were
	attacking our code through automated refactorings that we trusted
	to apply without tests. Mostly we applied a series of Extract
	Method refactorings to long methods in the process of performing a
	Compose Method refactoring on the long method. Eventually, your
	team will run out of situations where you can apply automated
	refactorings to improve the design of your code and you'll have
	to start applying actual code changes. Several of the commenters
	on my previous post remarked that making changes without unit
	tests implies risk that can only be averted with sufficient manual
	testing and that such risk is better mitigated by automated tests.
	In this followup post, I'll describe the results from our team at
	applying the decoupling techniques described by Michael Feathers
	to our legacy code so that we could backfill unit tests onto the
	legacy code in preparation for a design change we want to make.

Read the rest here <http://wp.me/pyVNs-eb>

--

-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
(Continue reading)

mike_ch_1 | 10 Oct 2009 14:16
Picon
Favicon

Using refactoring to make code more testable


Sent from my BlackBerry® wireless handheld

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

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

<*> To unsubscribe from this group, send an email to:
    refactoring-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

mike_ch_1 | 11 Oct 2009 19:03
Picon
Favicon

Re: Using refactoring to make code more testable

Oops ment to save this as a draft. I have largish code base (roughly 10 million lines) that my company deals
with and a much smaller code base (roughly 250 thousand lines) my team deals with. Currently there is no
unit test coverage of any of the code. And the code was not wrote to be tested. My main task is to get the code
covered.  I was wondering what kind of refactoring strategies would help make this goal attainable?

Thanks everyone. 
Sent from my BlackBerry® wireless handheld

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

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

<*> To unsubscribe from this group, send an email to:
    refactoring-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
(Continue reading)

Olof Bjarnason | 11 Oct 2009 19:26
Picon
Gravatar

Re: Using refactoring to make code more testable

2009/10/11  <mike_ch_1 <at> hotmail.com>:
> Oops ment to save this as a draft. I have largish code base (roughly 10 million lines) that my company deals
with and a much smaller code base (roughly 250 thousand lines) my team deals with. Currently there is no
unit test coverage of any of the code. And the code was not wrote to be tested. My main task is to get the code
covered.  I was wondering what kind of refactoring strategies would help make this goal attainable?

Hehe. Sorry but you have _A_LOT_OF_WORK_ ahead of you ;)

Go buy Michael Feathers "Working Efficiently with Legacy Code" first
of all. Read it and try to apply his techniques on the code "jungle"
that will be your home for the coming few years.

>
> Thanks everyone.
> Sent from my BlackBerry® wireless handheld
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--

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

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

Steven Gordon | 11 Oct 2009 20:08
Picon

Re: Using refactoring to make code more testable

Does the code already do what it is supposed to do?

Do you know what the code is really supposed to do?

On Sun, Oct 11, 2009 at 10:03 AM,  <mike_ch_1 <at> hotmail.com> wrote:
> Oops ment to save this as a draft. I have largish code base (roughly 10 million lines) that my company deals
with and a much smaller code base (roughly 250 thousand lines) my team deals with. Currently there is no
unit test coverage of any of the code. And the code was not wrote to be tested. My main task is to get the code
covered.  I was wondering what kind of refactoring strategies would help make this goal attainable?
>
> Thanks everyone.

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

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

(Continue reading)

George Dinwiddie | 11 Oct 2009 21:36
Favicon

Re: Using refactoring to make code more testable

mike_ch_1 <at> hotmail.com wrote:
> Oops ment to save this as a draft. I have largish code base (roughly
> 10 million lines) that my company deals with and a much smaller code
> base (roughly 250 thousand lines) my team deals with. Currently there
> is no unit test coverage of any of the code. And the code was not
> wrote to be tested. My main task is to get the code covered.  I was
> wondering what kind of refactoring strategies would help make this
> goal attainable?

First, read Michael Feathers' book, Working Effectively With Legacy 
Code.  It will help you find or create seams for testing.

Write tests that cover largish chunks of the system as /characterization 
tests/.  These are tests that characterize what the system currently 
does, whether that's right or wrong.  That will let you see when 
something changes, and you can investigate.

Then, as you work on the system, further isolate the part you're 
changing and add more fine-grained tests around that part.  TDD any new 
code you write.

It takes time, but this is a strategy that works.

  - George

--

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
(Continue reading)

Richard | 11 Oct 2009 21:48
Favicon
Gravatar

Re: Using refactoring to make code more testable Re: [refactoring] Using refactoring to make code more testable


In article <1932321348-1255280632-cardhu_decombobulator_blackberry.rim.net-1918218162- <at> bda056.bisx.prod.on.blackberry>,
    mike_ch_1 <at> hotmail.com, mike_ch_1 <at> hotmail.com  writes:

> My main task is to get the code covered.  [...]

To what end?

The three rules of programming apply:

1. Don't do it.
2. Don't do it again.
3. When all else fails, break rule 1.

In this context:

Don't write tests just for the sake of writing tests, particularly on
legacy code.  The changes you need to make to legacy code in order to
make it testable can just as likely introduce defects as they will
make the code testable.

If you have defects to fix in that legacy code, then do traditional
debugging to find the location of the fault and then do a minimal
amount of decoupling around the fault so you can write a failing test,
fix the fault and get a passing test.  Leave the rest alone.
--

-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
(Continue reading)

Adam Sroka | 11 Oct 2009 21:57
Picon
Gravatar

Re: Using refactoring to make code more testable

On Sun, Oct 11, 2009 at 12:36 PM, George Dinwiddie
<lists <at> idiacomputing.com> wrote:
> mike_ch_1 <at> hotmail.com wrote:
>> Oops ment to save this as a draft. I have largish code base (roughly
>> 10 million lines) that my company deals with and a much smaller code
>> base (roughly 250 thousand lines) my team deals with. Currently there
>> is no unit test coverage of any of the code. And the code was not
>> wrote to be tested. My main task is to get the code covered.  I was
>> wondering what kind of refactoring strategies would help make this
>> goal attainable?
>
> First, read Michael Feathers' book, Working Effectively With Legacy
> Code.  It will help you find or create seams for testing.
>
> Write tests that cover largish chunks of the system as /characterization
> tests/.  These are tests that characterize what the system currently
> does, whether that's right or wrong.  That will let you see when
> something changes, and you can investigate.
>
> Then, as you work on the system, further isolate the part you're
> changing and add more fine-grained tests around that part.  TDD any new
> code you write.
>
> It takes time, but this is a strategy that works.
>

I like the characterization tests approach, and I have seen it work as
well. A variation that I like is to move from programmer focused
characterization tests to ATDD style tests. This works if you can get
your hands on a customer who has a good idea what the system /should/
(Continue reading)

Adam Sroka | 11 Oct 2009 22:19
Picon
Gravatar

Re: Using refactoring to make code more testable Re: [refactoring] Using refactoring to make code more testable

On Sun, Oct 11, 2009 at 12:48 PM, Richard <legalize <at> xmission.com> wrote:
>
>
>
> In article <1932321348-1255280632-cardhu_decombobulator_blackberry.rim.net-1918218162- <at> bda056.bisx.prod.on.blackberry>,
> mike_ch_1 <at> hotmail.com, mike_ch_1 <at> hotmail.com writes:
>
> > My main task is to get the code covered. [...]
>
> To what end?
>
> The three rules of programming apply:
>
> 1. Don't do it.
> 2. Don't do it again.
> 3. When all else fails, break rule 1.
>

I don't know where that comes from. It's cute, but makes no practical
sense to me.

> In this context:
>
> Don't write tests just for the sake of writing tests, particularly on
> legacy code. The changes you need to make to legacy code in order to
> make it testable can just as likely introduce defects as they will
> make the code testable.
>

No one writes tests for the sake of writing tests. We write tests so
(Continue reading)


Gmane