开云体育

It is, though you could easily replace that with any cache implementation.
Most web server caches are global/static by design, though. The main
point is the separation of concerns and use of abstractions to make your
code less coupled to the cache implementation.

On Saturday, June 29, 2013, David Burstin wrote:

**


Hi Steve. Thanks for the links. I had a look at the blog and unless I am
mistaken it is still just using a static cache internally -
HttpRuntime.Cache.

Am I missing something?
On 29/06/2013 12:55 AM, "Steve Smith" <ssmith.lists@...<javascript:_e({}, 'cvml', 'ssmith.lists%40gmail.com');>>
wrote:

I would avoid the statics, replace the references to the repositories

with

interfaces, and also split the responsibility to cache or access data

into

two pieces, so that each can be tested (and evolve) independently. For
more on this last part, see my article series on the CachedRepository
pattern:



If you happen to have a Pluralsight subscription (or grab the free trial)
there's a 6 minute demo showing this implementation as part of the Proxy
Design Pattern course, here:


Cheers,
Steve


On Wed, Jun 26, 2013 at 10:52 AM, David Burstin <david.burstin@...<javascript:_e({}, 'cvml', 'david.burstin%40gmail.com');>

wrote:

**


Hi folks,

I've got a question around design for a legacy project that I am

working

on

in c#.

This project uses some repository classes that internally act as

caches,

retrieving data from internal lists and only hitting the database if

the

items are not found. These are all implemented as static methods -
effectively acting as globals. The static repositories provide the

benefits

of global accessibility throughout the project as well as a single

internal

long-lived cache.

My problem is that I am trying to test some classes that use these
repositories as collaborators, but don't have a good way of

mocking/faking

the repositories as (a) they don't have any interfaces and (b) they are

not

instances, so cannot be injected.

One option is to add static methods to the repositories to inject

canned

data into their internal lists for testing, but that seems wrong to me

-

it

exposes their internal implementation and breaks encapsulation (is

there

such a thing with static objects?).

Another is to create an interface and have the production code use a
concrete implementation that internally calls the static methods.In

testing

I can inject mocks. Again, this seems messy to me.

I personally don't like the use of static objects, but I don't know

what

a

better alternative is that would provide long-lived caching and easy
accessibility from anywhere in the code. Everyone else on the team

thinks

that they are a great solution.

What do you guys think? Is there a good way to test this scenario that

I

am

missing? Or is the design smelly as I suspect?

Cheers
David

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

--
Steve Smith








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

Yahoo! Groups Links

--
Steve Smith




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

Hi Steve. Thanks for the links. I had a look at the blog and unless I am
mistaken it is still just using a static cache internally -
HttpRuntime.Cache.

Am I missing something?

I used this approach at a company-that-shall-not-be-named, years ago.

I started with 2 unit tests for my group's part of the system. A week later I was up to 10, and my co-workers started seeing that I was able to work more quickly than they, so they added their own. Six months later, it was clear to the rest of the organization that we were working much faster and breaking the overall build much less frequently than everybody else. After a year, most of the organization was doing unit testing.

Good luck and let us know how you're doing!

- Russ

On Jun 27, 2013, at 7:06 PM, David Burstin <david.burstin@...> wrote:

Thanks Russ. That is exactly the way I am going to start.

Amazingly I even met some resistance to that approach - "it will be
inconsistent with the rest of the application", "someone new coming along
won't understand what is going on" ...

I have managed to convince them by showing the difficulties of unit testing
as the code stands, although they were happy just doing slow running
end-to-end tests and assuming that since the few test cases passed then the
whole system was fine. The standard policy is that for every 10 hours of
coding we need to allocate 3 hours of future defect fixing! I am hoping to
change that. Slowly, slowly...


On 27 June 2013 23:51, Russell Gold <russ@...> wrote:

**


How much code control does the organization exert? Do you have regular
code reviews?

My experience is that the best way is to start small. Make one class
testable at a time without touching the caches. Use facade interfaces as
wrappers to deal with your statics. For example, in Java I might do
something like this:

Existing static:

public static ThingIWant getThingIWant() { accesses the db and caches the
result }

Existing class:

class MyClass {

:

void doSomething() {
ThingIWant aThing = ThatStaticClass.getThingIWant();
process(aThing);
}
}

Modified class

class MyClass {
interface SomeInterface {
ThingIWant getThingIWant();
}

static class LiveProxy implements SomeInterface {
public ThingIWant getThingIWant() {
return ThatStaticClass.getThingIWant();
}
}

// test constructor
MyClass(SomeInterface interface) {
this.interface = interface;
}

// production constructor
public MyClass() {
this(new LiveProxy())
}

/// modified method
void doSomething() {
ThingIWant aThing = this.interface.getThingIWant();
process(aThing);
}

Your code is now testable - you supply a test version of the interface
when you instantiate it, and can control the object returned. The
production code uses the same interface, but supplies a production version
which accesses the statics. You don't need to persuade anybody of anything,
other than your code reviewers. The rest of the system remains unchanged.

At some point in the future, once you have an acceptable level of code
coverage, you can tackle changing the statics, but I'd put that off as long
as possible.

The important thing is to start by testing as much as you can while making
as few changes as possible.

- Russ



On Jun 27, 2013, at 2:59 AM, David Burstin <david.burstin@...>
wrote:

As far as code smells go, some people just seem to have blocked noses!

Anyway, thanks everyone for your answers. I'm glad to see that I am on

the

right track - now I just have to convince everyone else. I think the best
way forward is baby steps. I will start by encapsulating the statics

inside

a concrete implementation with a well-defined interface. Even that might
take some convincing! But at least it will give the opportunity to do

some

good testing.

I am looking at the possibility of using a DI framework to replace the
singleton caches, but that will be a HUGE leap for these guys. What do

you

guys feel is the best strategy for caching without having to pass around

an

entire collection of cache instances?


Cheers
David


On 27 June 2013 04:24, Steven Gordon <sgordonphd@...> wrote:

On Wed, Jun 26, 2013 at 10:54 AM, Michal Svoboda <pht@...>

wrote:

**

Everyone else on the team thinks that they are a great solution.

I hear you. It's not easy to convince others of their design problems
unless there is hard factual evidence. Look around the user code of

that

object and you'll find the smells.

Or there might not be any convincing enough smells, yet!

If not, bide your time, watch for smells as the code scales, and when
convincing smells appear, then make the case for refactoring it away
(trying not to say "I told you so").

One benefit is that there may be more information later to indicate what
the most appropriate alternative would be.

SteveG

Michal Svoboda

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

Yahoo! Groups Links

-----------------
Come read my webnovel, Take a Lemon <>,
and listen to the Misfile radio play <
>!

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

Yahoo! Groups Links

-----------------
Come read my webnovel, Take a Lemon <>,
and listen to the Misfile radio play <>!

On 2013 Jun 27, at 4:06 PM, David Burstin <david.burstin@...> wrote:

The standard policy is that for every 10 hours of
coding we need to allocate 3 hours of future defect fixing!

Wow. I knew a programmer who was dinged by her manager because she wasn't creating enough bugs. They expected a certain number of bugs per some number of lines of code to be found in code-review and testing.

--
C. Keith Ray
* 650-533-6535
*
*

I would avoid the statics, replace the references to the repositories with
interfaces, and also split the responsibility to cache or access data into
two pieces, so that each can be tested (and evolve) independently. For
more on this last part, see my article series on the CachedRepository
pattern:



If you happen to have a Pluralsight subscription (or grab the free trial)
there's a 6 minute demo showing this implementation as part of the Proxy
Design Pattern course, here:


Cheers,
Steve


On Wed, Jun 26, 2013 at 10:52 AM, David Burstin <david.burstin@...>wrote:

**


Hi folks,

I've got a question around design for a legacy project that I am working on
in c#.

This project uses some repository classes that internally act as caches,
retrieving data from internal lists and only hitting the database if the
items are not found. These are all implemented as static methods -
effectively acting as globals. The static repositories provide the benefits
of global accessibility throughout the project as well as a single internal
long-lived cache.

My problem is that I am trying to test some classes that use these
repositories as collaborators, but don't have a good way of mocking/faking
the repositories as (a) they don't have any interfaces and (b) they are not
instances, so cannot be injected.

One option is to add static methods to the repositories to inject canned
data into their internal lists for testing, but that seems wrong to me - it
exposes their internal implementation and breaks encapsulation (is there
such a thing with static objects?).

Another is to create an interface and have the production code use a
concrete implementation that internally calls the static methods.In testing
I can inject mocks. Again, this seems messy to me.

I personally don't like the use of static objects, but I don't know what a
better alternative is that would provide long-lived caching and easy
accessibility from anywhere in the code. Everyone else on the team thinks
that they are a great solution.

What do you guys think? Is there a good way to test this scenario that I am
missing? Or is the design smelly as I suspect?

Cheers
David

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

--
Steve Smith

Hello Harvis

I have quite a few articles on my blog and website about applying TDD to embedded systems software development. There's my book too :-)

More specifically, I have a series of three articles on testing code next to the RTOS. The ideas are applicable concurrent programming outside of embedded.

Unit testing RTOS dependent code – RTOS Test-Double

Unit testing RTOS dependent code – RTOS Test-Double – Part 2

Unit testing RTOS dependent code – RTOS Test-Double – Part 3


Let me know if they help.

James

--------------------------------------------------------------------------------------------
James Grenning Author of TDD for Embedded C
james@...
www.renaissancesoftware.net
www.renaissancesoftware.net/blog
www.twitter.com/jwgrenning

Hi David,

I assume you meant me and the discussion in the other thread.

To me the biggest negative side-effect is the difficulty in testing. I
believe this is a real issue. It is not just that there is no real way to
test if the solution works, only that it works most of the time in the
situations that we can think of. It is that the code is potentially brittle
and fragile.

I am a firm believer in refactoring. Code is a living, breathing thing. It
needs to grow and it needs to change in order to be able to adapt to a
changing world. The code must be maintainable and the cost of maintenance
must be kept as low as possible. It must be possible to add new features
and modify existing ones without too much pain. This is where refactoring
comes in - allowing us to make code pliable, to separate responsibilities,
to keep changes localized to the areas that need changing.

Without the safety net of tests (and I don't mean integrated tests as
integrated
tests are a scam<>
-
I mean that in the way JB means it), then refactoring is just code and
pray. So for me, the actual and real negative side effect of hard-to-test
code is that it is dangerous to refactor, and therefore difficult to
maintain.

Another actual negative side-effect is that this company has been forced
into standardizing defects - in other words defects are a built in part of
the process. I don't want to produce code expecting defects. I want to
expect no defects and to be disappointed when there are defects.

A third actual negative side-effect is that the code is not reusable. If I
can't use this code as a client in a test then I have no chance of using it
in any other scenario apart from the current one. It is bolted in too tight.

And finally, I can't make use of the opportunities presented by OO
programming. I find the inability to define responsibilities via interfaces
to be a big negative. The design tends towards a big ball of mud where
there are no clear boundaries and everything may or may not depend on
everything else.

And as it stands, every time an (expected) defect surfaces, all we can do
is code and pray.

Regards
David


On 28 June 2013 07:51, Parsons, David <d.p.parsons@...> wrote:

**


David,

I'm interested to read this discussion, but what I'm missing is an
explanation of what kinds of problems are being caused by the current
architecture. Presumably the remainder of the team will only see the value
of a new approach if there are evident issues with the current one. Not
liking what the code looks like is not in itself a problem. Do you have
some illuminating examples of where negative side-effects are arising? Is
it just that it is hard to test? Or is there more to it than that?

Dave

**
Dr. David Parsons
Associate Professor of Information Technology
School of Engineering and Advanced Technology
Massey University
Auckland, New Zealand

Ph: 0064 (0)9 414 0800 ext. 43135
Email: D.P.Parsons@...
Web:
***

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

I just want to add that you might need to convince your coworkers to keep unit tests passing.

If they are further convinced of the usefulness of writing tests, then you can show them up how helpful refactoring for testability is.

--
C. Keith Ray
* 650-533-6535
*
*

Thanks Russ. That is exactly the way I am going to start.

Amazingly I even met some resistance to that approach - "it will be
inconsistent with the rest of the application", "someone new coming along
won't understand what is going on" ...

I have managed to convince them by showing the difficulties of unit testing
as the code stands, although they were happy just doing slow running
end-to-end tests and assuming that since the few test cases passed then the
whole system was fine. The standard policy is that for every 10 hours of
coding we need to allocate 3 hours of future defect fixing! I am hoping to
change that. Slowly, slowly...


On 27 June 2013 23:51, Russell Gold <russ@...> wrote:

**


How much code control does the organization exert? Do you have regular
code reviews?

My experience is that the best way is to start small. Make one class
testable at a time without touching the caches. Use facade interfaces as
wrappers to deal with your statics. For example, in Java I might do
something like this:

Existing static:

public static ThingIWant getThingIWant() { accesses the db and caches the
result }

Existing class:

class MyClass {

:

void doSomething() {
ThingIWant aThing = ThatStaticClass.getThingIWant();
process(aThing);
}
}

Modified class

class MyClass {
interface SomeInterface {
ThingIWant getThingIWant();
}

static class LiveProxy implements SomeInterface {
public ThingIWant getThingIWant() {
return ThatStaticClass.getThingIWant();
}
}

// test constructor
MyClass(SomeInterface interface) {
this.interface = interface;
}

// production constructor
public MyClass() {
this(new LiveProxy())
}

/// modified method
void doSomething() {
ThingIWant aThing = this.interface.getThingIWant();
process(aThing);
}

Your code is now testable - you supply a test version of the interface
when you instantiate it, and can control the object returned. The
production code uses the same interface, but supplies a production version
which accesses the statics. You don't need to persuade anybody of anything,
other than your code reviewers. The rest of the system remains unchanged.

At some point in the future, once you have an acceptable level of code
coverage, you can tackle changing the statics, but I'd put that off as long
as possible.

The important thing is to start by testing as much as you can while making
as few changes as possible.

- Russ



On Jun 27, 2013, at 2:59 AM, David Burstin <david.burstin@...>
wrote:

As far as code smells go, some people just seem to have blocked noses!

Anyway, thanks everyone for your answers. I'm glad to see that I am on

the

right track - now I just have to convince everyone else. I think the best
way forward is baby steps. I will start by encapsulating the statics

inside

a concrete implementation with a well-defined interface. Even that might
take some convincing! But at least it will give the opportunity to do

some

good testing.

I am looking at the possibility of using a DI framework to replace the
singleton caches, but that will be a HUGE leap for these guys. What do

you

guys feel is the best strategy for caching without having to pass around

an

entire collection of cache instances?


Cheers
David


On 27 June 2013 04:24, Steven Gordon <sgordonphd@...> wrote:

On Wed, Jun 26, 2013 at 10:54 AM, Michal Svoboda <pht@...>

wrote:

**

Everyone else on the team thinks that they are a great solution.

I hear you. It's not easy to convince others of their design problems
unless there is hard factual evidence. Look around the user code of

that

object and you'll find the smells.

Or there might not be any convincing enough smells, yet!

If not, bide your time, watch for smells as the code scales, and when
convincing smells appear, then make the case for refactoring it away
(trying not to say "I told you so").

One benefit is that there may be more information later to indicate what
the most appropriate alternative would be.

SteveG

Michal Svoboda

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



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

Yahoo! Groups Links

-----------------
Come read my webnovel, Take a Lemon <>,
and listen to the Misfile radio play <
>!


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

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

David,

I'm interested to read this discussion, but what I'm missing is an explanation of what kinds of problems are being caused by the current architecture. Presumably the remainder of the team will only see the value of a new approach if there are evident issues with the current one. Not liking what the code looks like is not in itself a problem. Do you have some illuminating examples of where negative side-effects are arising? Is it just that it is hard to test? Or is there more to it than that?

Dave

**
Dr. David Parsons
Associate Professor of Information Technology
School of Engineering and Advanced Technology
Massey University
Auckland, New Zealand

Ph: 0064 (0)9 414 0800 ext. 43135
Email: D.P.Parsons@...
Web:
***

How much code control does the organization exert? Do you have regular code reviews?

My experience is that the best way is to start small. Make one class testable at a time without touching the caches. Use facade interfaces as wrappers to deal with your statics. For example, in Java I might do something like this:

Existing static:

public static ThingIWant getThingIWant() { accesses the db and caches the result }

Existing class:

class MyClass {

:

void doSomething() {
ThingIWant aThing = ThatStaticClass.getThingIWant();
process(aThing);
}
}


Modified class

class MyClass {
interface SomeInterface {
ThingIWant getThingIWant();
}

static class LiveProxy implements SomeInterface {
public ThingIWant getThingIWant() {
return ThatStaticClass.getThingIWant();
}
}

// test constructor
MyClass(SomeInterface interface) {
this.interface = interface;
}

// production constructor
public MyClass() {
this(new LiveProxy())
}

/// modified method
void doSomething() {
ThingIWant aThing = this.interface.getThingIWant();
process(aThing);
}


Your code is now testable - you supply a test version of the interface when you instantiate it, and can control the object returned. The production code uses the same interface, but supplies a production version which accesses the statics. You don't need to persuade anybody of anything, other than your code reviewers. The rest of the system remains unchanged.

At some point in the future, once you have an acceptable level of code coverage, you can tackle changing the statics, but I'd put that off as long as possible.

The important thing is to start by testing as much as you can while making as few changes as possible.

- Russ


On Jun 27, 2013, at 2:59 AM, David Burstin <david.burstin@...> wrote:

As far as code smells go, some people just seem to have blocked noses!

Anyway, thanks everyone for your answers. I'm glad to see that I am on the
right track - now I just have to convince everyone else. I think the best
way forward is baby steps. I will start by encapsulating the statics inside
a concrete implementation with a well-defined interface. Even that might
take some convincing! But at least it will give the opportunity to do some
good testing.

I am looking at the possibility of using a DI framework to replace the
singleton caches, but that will be a HUGE leap for these guys. What do you
guys feel is the best strategy for caching without having to pass around an
entire collection of cache instances?


Cheers
David


On 27 June 2013 04:24, Steven Gordon <sgordonphd@...> wrote:

On Wed, Jun 26, 2013 at 10:54 AM, Michal Svoboda <pht@...> wrote:

**

Everyone else on the team thinks that they are a great solution.

I hear you. It's not easy to convince others of their design problems
unless there is hard factual evidence. Look around the user code of that
object and you'll find the smells.

Or there might not be any convincing enough smells, yet!

If not, bide your time, watch for smells as the code scales, and when
convincing smells appear, then make the case for refactoring it away
(trying not to say "I told you so").

One benefit is that there may be more information later to indicate what
the most appropriate alternative would be.

SteveG

Michal Svoboda

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

Yahoo! Groups Links

-----------------
Come read my webnovel, Take a Lemon <>,
and listen to the Misfile radio play <>!

As far as code smells go, some people just seem to have blocked noses!

Anyway, thanks everyone for your answers. I'm glad to see that I am on the
right track - now I just have to convince everyone else. I think the best
way forward is baby steps. I will start by encapsulating the statics inside
a concrete implementation with a well-defined interface. Even that might
take some convincing! But at least it will give the opportunity to do some
good testing.

I am looking at the possibility of using a DI framework to replace the
singleton caches, but that will be a HUGE leap for these guys. What do you
guys feel is the best strategy for caching without having to pass around an
entire collection of cache instances?


Cheers
David

On Wed, Jun 26, 2013 at 10:54 AM, Michal Svoboda <pht@...> wrote:

**

Everyone else on the team thinks that they are a great solution.

I hear you. It's not easy to convince others of their design problems
unless there is hard factual evidence. Look around the user code of that
object and you'll find the smells.

Or there might not be any convincing enough smells, yet!

If not, bide your time, watch for smells as the code scales, and when
convincing smells appear, then make the case for refactoring it away
(trying not to say "I told you so").

One benefit is that there may be more information later to indicate what
the most appropriate alternative would be.

SteveG

Michal Svoboda

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

David Burstin wrote:

One option is to add static methods to the repositories to inject canned
data into their internal lists for testing, but that seems wrong to me - it
exposes their internal implementation and breaks encapsulation (is there
such a thing with static objects?).

This is a "pattern" from the book "working with legacy code" - it's good
because it's (relatively) non-invasive and allows you to put your legacy
code under test for further refactoring. So good but temporary solution.

If you're afraid the setters will be used from normal code you can guard
by a boolean that a test must set first.

Another is to create an interface and have the production code use a
concrete implementation that internally calls the static methods.In testing
I can inject mocks. Again, this seems messy to me.

Can you substitute the database itself and let your test data be cached
as they normally would? It's always better to "mock" as little as
possible to avoid tests diverging from reality.

I personally don't like the use of static objects, but I don't know what a
better alternative is that would provide long-lived caching and easy
accessibility from anywhere in the code.

Caches don't need to be static, they just need to be reachable enough so
that they can cache something. Accessibility from anywhere in the code
is actually a design smell I think.

Everyone else on the team thinks that they are a great solution.

I hear you. It's not easy to convince others of their design problems
unless there is hard factual evidence. Look around the user code of that
object and you'll find the smells.

Michal Svoboda

On Wed, Jun 26, 2013 at 10:52 AM, David Burstin <david.burstin@...>wrote:

**


Another is to create an interface and have the production code use a
concrete implementation that internally calls the static methods.In testing
I can inject mocks. Again, this seems messy to me.

Not having seen the code my gut tells me that this is probably what I would
do. Just create a wrapper API that lets you use the cache in a more OO way
and then write a concrete implementation that delegates to the statics. You
can mock that interface in your tests.

I personally don't like the use of static objects, but I don't know what a
better alternative is that would provide long-lived caching and easy
accessibility from anywhere in the code. Everyone else on the team thinks
that they are a great solution.

I would consider the statics a smell. Creating the wrapper API gives you a
seam to test from, and then once you have coverage you can think about
refactoring the statics out without changing the API.

Hi folks,

I've got a question around design for a legacy project that I am working on
in c#.

This project uses some repository classes that internally act as caches,
retrieving data from internal lists and only hitting the database if the
items are not found. These are all implemented as static methods -
effectively acting as globals. The static repositories provide the benefits
of global accessibility throughout the project as well as a single internal
long-lived cache.

My problem is that I am trying to test some classes that use these
repositories as collaborators, but don't have a good way of mocking/faking
the repositories as (a) they don't have any interfaces and (b) they are not
instances, so cannot be injected.

One option is to add static methods to the repositories to inject canned
data into their internal lists for testing, but that seems wrong to me - it
exposes their internal implementation and breaks encapsulation (is there
such a thing with static objects?).

Another is to create an interface and have the production code use a
concrete implementation that internally calls the static methods.In testing
I can inject mocks. Again, this seems messy to me.

I personally don't like the use of static objects, but I don't know what a
better alternative is that would provide long-lived caching and easy
accessibility from anywhere in the code. Everyone else on the team thinks
that they are a great solution.

What do you guys think? Is there a good way to test this scenario that I am
missing? Or is the design smelly as I suspect?

Cheers
David

在 Tue, 04 Jun 2013 00:10:26 +0800，Esko Luontola
<esko.luontola@...> 写道:

Kathy Van Stone wrote on 3.6.2013 18:55:

I gave a lightning talk on Test Driven Development. Obviously I could
not
go into details, but I was wondering if there is a (current) good link
to
send people for more information? I've been a bit out of touch with
teaching it of late.

Here is my recommendation for people wanting to learn it:

Any good example of TDD used in embedded system developing especially with
RTOS.
I'm a new guy with TDD, now what I so write non-hardware code in Dev C++
than copy it
to my embedded software project for continue test, it's little complex.

Thanks a lot.
----
Harvis Wang

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

Kathy Van Stone wrote on 3.6.2013 18:55:

I gave a lightning talk on Test Driven Development. Obviously I could not
go into details, but I was wondering if there is a (current) good link to
send people for more information? I've been a bit out of touch with
teaching it of late.

Here is my recommendation for people wanting to learn it:


--
Esko Luontola
www.orfjackal.net

I gave a lightning talk on Test Driven Development. Obviously I could not
go into details, but I was wondering if there is a (current) good link to
send people for more information? I've been a bit out of touch with
teaching it of late.

Thanks,

Kathy