Re: [TDD] Testing business rules and not deploying the entire stack
Hi Rakesh, First off I think it's good to clarify what your actual business requirements are - is the REST API *really* part of your business requirements or is this actually an infrastructure thing? Getting the right answer to this should start to push you in the right direction. Can I ask what you mean by the full stack? Do you mean a bunch of web services coordinating together + web page or are we talking more single REST service? There are many layers of testing you can apply to ensure you're covering what you want, and the further up the stack you go the less of them there are. Regardless of your ultimate stack, it is always a good idea to step away from your infrastructure as soon as possible, ala ports and adapters. Have your REST implementation have a single responsibility of handling the HTTP part and *nothing else*. Push in a collaborator and have that handle all the rest of the work. In this way you can have a suite of tests that run against that collaborator and ignore the HTTP part. This can be where the core of your high level tests go - and they're just Java code so you can apply whatever faking/mocking you *need* to and keep them fast. I would also have a few higher level tests that actually poke the HTTP as well - but this is a much smaller subset that just verify the plumbing and let you drive the initial implementation. If you have multiple services talking to each other, have yet another level of tests that just smoke test the plumbing between them. Hope this helps On Tue, Apr 2, 2013 at 3:53 PM, rakesh mailgroups < rakesh.mailgroups@...> wrote: **
Hi,
I'm building a new system and I want to get it 'right'.
What does right mean? It means I want to test my business rules against
just Java classes.
This approach has been advocated by Uncle Bob (I believe) and is very
seductive because I have worked on many projects where eventually, due to
running on a full stack, the test suite begins to slow down drastically.
The approach seems to be to express your business requirements in a
non-infrastructure related way. I can just about see this with a web app
with a html front end. Instead of saying 'click button Add User', you could
say 'select Add User' and call the underlying service call that the
controller was going to.
(You still don't know if the button works of course, but you could have a
few, full stack tests to make sure).
This approach has some disadvantages though. The main one being you cannot
always separate the business requirements and the infrastructure.
A classic example is a RESTful web service. The business requirements are
full of GET, POST, DELETE, PUT, urls, application media types and JSON
payloads. Writing requirements in this language makes sense to everybody
involved including public consumers of the service and to abstract away the
http infrastructure seems wrong.
Of course, once I start running my tests against a deployed web app, I am
now back to square one regarding quantity of tests and how long they take
to run.
Any suggestions?
Thanks
[Non-text portions of this message have been removed]
-- Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head. Something which you, I, and everyone else would call "Tuesday", of course.
|
Re: [TDD] Re: Testing business rules and not deploying the entire stack
I'm so sorry I got your name wrong. Don't know what I was thinking
toggle quoted message
Show quoted text
On Thu, Apr 4, 2013 at 9:22 AM, Matteo Vaccari <vaccari@...> wrote: Hi Debasish,
my strategy is to let the fw call me, and avoid dependencies on the
framework in my code. It was fairly successful in a project one year ago.
Our entry point was a single servlet, that called our own routing object,
that selected the appropriate controller factory, that created the
controller and so on. It is very fast, memory efficient and easy to test.
BTW in our project we also used end-to-end tests.
Matteo
On Wed, Apr 3, 2013 at 6:43 PM, <patel.rakesh@...> wrote:
hmm, I responded this morning but my reply hasn't shown up yet! Copying
my reponse:
Hi Matteo,
an approach that like that would have consequences for how to use the
REST framework.
For example, lets take Spring MVC. The traditional approach is to create
a controller for a specific use case and use annotations for GET and POST.
The url routing would also be done via annotations and so passing that into
the business layer would be irrelevant.
However, if I had just one controller that received all incoming
requests, and then methods for GET, POST, DELETE and PUT which gathered all
the params and the url and passed to the next layer, it could work. This
controller is clueless which use case I need.
But I've never seen that approach in the wild and definitely not in any
REST framework code.
Any thoughts?
Then i added:
actually, thinking this through, I can see other issues.
Lets say use case A returns object Foo for a GET and use case B returns
object Bar for a GET. A generic GET method in one super controller would
need to know which business method to call to return the right type. Thats
logic thats not easily tested.
If I go back to the use case per controller pattern, then I know in the
GET method what the return type should be, but now there no point passing
in the url that was called because it was already routed (and un-tested).
It seems I would have to compromise somewhere and hope that the area I
left untested is too simple to go wrong such as routing. Perhaps a few
integration tests with a container to test the routing would alleviate
this? Or to test the correct business layer method is called?
--- In testdrivendevelopment@..., Matteo Vaccari <vaccari@...>
wrote:
On Tue, Apr 2, 2013 at 4:53 PM, rakesh mailgroups <
rakesh.mailgroups@...> wrote:
Hi,
I'm building a new system and I want to get it 'right'.
What does right mean? It means I want to test my business rules
against
just Java classes.
This approach has been advocated by Uncle Bob (I believe) and is very
seductive because I have worked on many projects where eventually,
due to
running on a full stack, the test suite begins to slow down
drastically.
The approach seems to be to express your business requirements in a
non-infrastructure related way. I can just about see this with a web
app
with a html front end. Instead of saying 'click button Add User', you
could
say 'select Add User' and call the underlying service call that the
controller was going to.
(You still don't know if the button works of course, but you could
have a
few, full stack tests to make sure).
This approach has some disadvantages though. The main one being you
cannot
always separate the business requirements and the infrastructure.
A classic example is a RESTful web service. The business requirements
are
full of GET, POST, DELETE, PUT, urls, application media types and JSON
payloads. Writing requirements in this language makes sense to
everybody
involved including public consumers of the service and to abstract
away the
http infrastructure seems wrong.
Of course, once I start running my tests against a deployed web app,
I am
now back to square one regarding quantity of tests and how long they
take
to run.
Any suggestions?
Thanks
Hi Rakesh,
the trick I would use if I were you is to create my "business" object
inside the servlet (or action class or whatever your preferred web
framework asks you to use.) I would pass to this object the method,
parameters, uri and whatever else it needs, and I would test that it
returns the proper status code, attributes and body.
There is a longer description of how to do it in this post by Misko
Hevery
Matteo
------------------------------------
Yahoo! Groups Links
|
Re: [TDD] Re: Testing business rules and not deploying the entire stack
Hi Debasish,
my strategy is to let the fw call me, and avoid dependencies on the
framework in my code. It was fairly successful in a project one year ago.
Our entry point was a single servlet, that called our own routing object,
that selected the appropriate controller factory, that created the
controller and so on. It is very fast, memory efficient and easy to test.
BTW in our project we also used end-to-end tests.
Matteo
toggle quoted message
Show quoted text
On Wed, Apr 3, 2013 at 6:43 PM, <patel.rakesh@...> wrote: hmm, I responded this morning but my reply hasn't shown up yet! Copying my
reponse:
Hi Matteo,
an approach that like that would have consequences for how to use the REST
framework.
For example, lets take Spring MVC. The traditional approach is to create a
controller for a specific use case and use annotations for GET and POST.
The url routing would also be done via annotations and so passing that into
the business layer would be irrelevant.
However, if I had just one controller that received all incoming requests,
and then methods for GET, POST, DELETE and PUT which gathered all the
params and the url and passed to the next layer, it could work. This
controller is clueless which use case I need.
But I've never seen that approach in the wild and definitely not in any
REST framework code.
Any thoughts?
Then i added:
actually, thinking this through, I can see other issues.
Lets say use case A returns object Foo for a GET and use case B returns
object Bar for a GET. A generic GET method in one super controller would
need to know which business method to call to return the right type. Thats
logic thats not easily tested.
If I go back to the use case per controller pattern, then I know in the
GET method what the return type should be, but now there no point passing
in the url that was called because it was already routed (and un-tested).
It seems I would have to compromise somewhere and hope that the area I
left untested is too simple to go wrong such as routing. Perhaps a few
integration tests with a container to test the routing would alleviate
this? Or to test the correct business layer method is called?
--- In testdrivendevelopment@..., Matteo Vaccari <vaccari@...>
wrote:
On Tue, Apr 2, 2013 at 4:53 PM, rakesh mailgroups <
rakesh.mailgroups@...> wrote:
Hi,
I'm building a new system and I want to get it 'right'.
What does right mean? It means I want to test my business rules against
just Java classes.
This approach has been advocated by Uncle Bob (I believe) and is very
seductive because I have worked on many projects where eventually, due
to
running on a full stack, the test suite begins to slow down
drastically.
The approach seems to be to express your business requirements in a
non-infrastructure related way. I can just about see this with a web
app
with a html front end. Instead of saying 'click button Add User', you
could
say 'select Add User' and call the underlying service call that the
controller was going to.
(You still don't know if the button works of course, but you could
have a
few, full stack tests to make sure).
This approach has some disadvantages though. The main one being you
cannot
always separate the business requirements and the infrastructure.
A classic example is a RESTful web service. The business requirements
are
full of GET, POST, DELETE, PUT, urls, application media types and JSON
payloads. Writing requirements in this language makes sense to
everybody
involved including public consumers of the service and to abstract
away the
http infrastructure seems wrong.
Of course, once I start running my tests against a deployed web app, I
am
now back to square one regarding quantity of tests and how long they
take
to run.
Any suggestions?
Thanks
Hi Rakesh,
the trick I would use if I were you is to create my "business" object
inside the servlet (or action class or whatever your preferred web
framework asks you to use.) I would pass to this object the method,
parameters, uri and whatever else it needs, and I would test that it
returns the proper status code, attributes and body.
There is a longer description of how to do it in this post by Misko
Hevery
Matteo
------------------------------------
Yahoo! Groups Links
|
Re: Testing business rules and not deploying the entire stack
hmm, I responded this morning but my reply hasn't shown up yet! Copying my reponse:
Hi Matteo,
an approach that like that would have consequences for how to use the REST framework.
For example, lets take Spring MVC. The traditional approach is to create a controller for a specific use case and use annotations for GET and POST. The url routing would also be done via annotations and so passing that into the business layer would be irrelevant.
However, if I had just one controller that received all incoming requests, and then methods for GET, POST, DELETE and PUT which gathered all the params and the url and passed to the next layer, it could work. This controller is clueless which use case I need.
But I've never seen that approach in the wild and definitely not in any REST framework code.
Any thoughts?
Then i added:
actually, thinking this through, I can see other issues.
Lets say use case A returns object Foo for a GET and use case B returns object Bar for a GET. A generic GET method in one super controller would need to know which business method to call to return the right type. Thats logic thats not easily tested.
If I go back to the use case per controller pattern, then I know in the GET method what the return type should be, but now there no point passing in the url that was called because it was already routed (and un-tested).
It seems I would have to compromise somewhere and hope that the area I left untested is too simple to go wrong such as routing. Perhaps a few integration tests with a container to test the routing would alleviate this? Or to test the correct business layer method is called?
toggle quoted message
Show quoted text
--- In testdrivendevelopment@..., Matteo Vaccari <vaccari@...> wrote:
On Tue, Apr 2, 2013 at 4:53 PM, rakesh mailgroups <
rakesh.mailgroups@...> wrote:
Hi,
I'm building a new system and I want to get it 'right'.
What does right mean? It means I want to test my business rules against
just Java classes.
This approach has been advocated by Uncle Bob (I believe) and is very
seductive because I have worked on many projects where eventually, due to
running on a full stack, the test suite begins to slow down drastically.
The approach seems to be to express your business requirements in a
non-infrastructure related way. I can just about see this with a web app
with a html front end. Instead of saying 'click button Add User', you could
say 'select Add User' and call the underlying service call that the
controller was going to.
(You still don't know if the button works of course, but you could have a
few, full stack tests to make sure).
This approach has some disadvantages though. The main one being you cannot
always separate the business requirements and the infrastructure.
A classic example is a RESTful web service. The business requirements are
full of GET, POST, DELETE, PUT, urls, application media types and JSON
payloads. Writing requirements in this language makes sense to everybody
involved including public consumers of the service and to abstract away the
http infrastructure seems wrong.
Of course, once I start running my tests against a deployed web app, I am
now back to square one regarding quantity of tests and how long they take
to run.
Any suggestions?
Thanks
Hi Rakesh,
the trick I would use if I were you is to create my "business" object
inside the servlet (or action class or whatever your preferred web
framework asks you to use.) I would pass to this object the method,
parameters, uri and whatever else it needs, and I would test that it
returns the proper status code, attributes and body.
There is a longer description of how to do it in this post by Misko Hevery
Matteo
[Non-text portions of this message have been removed]
|
Re: [TDD] Testing business rules and not deploying the entire stack
actually, thinking this through, I can see other issues. Lets say use case A returns object Foo for a GET and use case B returns object Bar for a GET. A generic GET method in one super controller would need to know which business method to call to return the right type. Thats logic thats not easily tested. If I go back to the use case per controller pattern, then I know in the GET method what the return type should be, but now there no point passing in the url that was called because it was already routed (and un-tested). It seems I would have to compromise somewhere and hope that the area I left untested is too simple to go wrong such as routing. Perhaps a few integration tests with a container to test the routing would alleviate this? Or to test the correct business layer method is called? Rakesh On Wed, Apr 3, 2013 at 9:58 AM, rakesh mailgroups < rakesh.mailgroups@...> wrote: Hi Matteo,
an approach that like that would have consequences for how to use the REST
framework.
For example, lets take Spring MVC. The traditional approach is to create a
controller for a specific use case and use annotations for GET and POST.
The url routing would also be done via annotations and so passing that into
the business layer would be irrelevant.
However, if I had just one controller that received all incoming requests,
and then methods for GET, POST, DELETE and PUT which gathered all the
params and the url and passed to the next layer, it could work. This
controller is clueless which use case I need.
But I've never seen that approach in the wild and definitely not in any
REST framework code.
Any thoughts?
On Tue, Apr 2, 2013 at 5:14 PM, Matteo Vaccari <vaccari@...> wrote:
**
On Tue, Apr 2, 2013 at 4:53 PM, rakesh mailgroups <
rakesh.mailgroups@...> wrote:
Hi,
I'm building a new system and I want to get it 'right'.
What does right mean? It means I want to test my business rules against
just Java classes.
This approach has been advocated by Uncle Bob (I believe) and is very
seductive because I have worked on many projects where eventually, due to
running on a full stack, the test suite begins to slow down drastically.
The approach seems to be to express your business requirements in a
non-infrastructure related way. I can just about see this with a web app
with a html front end. Instead of saying 'click button Add User', you could
say 'select Add User' and call the underlying service call that the
controller was going to.
(You still don't know if the button works of course, but you could have a
few, full stack tests to make sure).
This approach has some disadvantages though. The main one being you cannot
always separate the business requirements and the infrastructure.
A classic example is a RESTful web service. The business requirements are
full of GET, POST, DELETE, PUT, urls, application media types and JSON
payloads. Writing requirements in this language makes sense to everybody
involved including public consumers of the service and to abstract away the
http infrastructure seems wrong.
Of course, once I start running my tests against a deployed web app, I am
now back to square one regarding quantity of tests and how long they take
to run.
Any suggestions?
Thanks
Hi Rakesh,
the trick I would use if I were you is to create my "business" object
inside the servlet (or action class or whatever your preferred web
framework asks you to use.) I would pass to this object the method,
parameters, uri and whatever else it needs, and I would test that it
returns the proper status code, attributes and body.
There is a longer description of how to do it in this post by Misko Hevery
Matteo
|
Re: [TDD] Testing business rules and not deploying the entire stack
Hi Matteo, an approach that like that would have consequences for how to use the REST framework. For example, lets take Spring MVC. The traditional approach is to create a controller for a specific use case and use annotations for GET and POST. The url routing would also be done via annotations and so passing that into the business layer would be irrelevant. However, if I had just one controller that received all incoming requests, and then methods for GET, POST, DELETE and PUT which gathered all the params and the url and passed to the next layer, it could work. This controller is clueless which use case I need. But I've never seen that approach in the wild and definitely not in any REST framework code. Any thoughts? On Tue, Apr 2, 2013 at 5:14 PM, Matteo Vaccari <vaccari@...> wrote: **
On Tue, Apr 2, 2013 at 4:53 PM, rakesh mailgroups <
rakesh.mailgroups@...> wrote:
Hi,
I'm building a new system and I want to get it 'right'.
What does right mean? It means I want to test my business rules against
just Java classes.
This approach has been advocated by Uncle Bob (I believe) and is very
seductive because I have worked on many projects where eventually, due to
running on a full stack, the test suite begins to slow down drastically.
The approach seems to be to express your business requirements in a
non-infrastructure related way. I can just about see this with a web app
with a html front end. Instead of saying 'click button Add User', you could
say 'select Add User' and call the underlying service call that the
controller was going to.
(You still don't know if the button works of course, but you could have a
few, full stack tests to make sure).
This approach has some disadvantages though. The main one being you cannot
always separate the business requirements and the infrastructure.
A classic example is a RESTful web service. The business requirements are
full of GET, POST, DELETE, PUT, urls, application media types and JSON
payloads. Writing requirements in this language makes sense to everybody
involved including public consumers of the service and to abstract away the
http infrastructure seems wrong.
Of course, once I start running my tests against a deployed web app, I am
now back to square one regarding quantity of tests and how long they take
to run.
Any suggestions?
Thanks
Hi Rakesh,
the trick I would use if I were you is to create my "business" object
inside the servlet (or action class or whatever your preferred web
framework asks you to use.) I would pass to this object the method,
parameters, uri and whatever else it needs, and I would test that it
returns the proper status code, attributes and body.
There is a longer description of how to do it in this post by Misko Hevery
Matteo
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
|
Re: [TDD] Testing business rules and not deploying the entire stack
On Tue, Apr 2, 2013 at 4:53 PM, rakesh mailgroups < rakesh.mailgroups@...> wrote: Hi,
I'm building a new system and I want to get it 'right'.
What does right mean? It means I want to test my business rules against
just Java classes.
This approach has been advocated by Uncle Bob (I believe) and is very
seductive because I have worked on many projects where eventually, due to
running on a full stack, the test suite begins to slow down drastically.
The approach seems to be to express your business requirements in a
non-infrastructure related way. I can just about see this with a web app
with a html front end. Instead of saying 'click button Add User', you could
say 'select Add User' and call the underlying service call that the
controller was going to.
(You still don't know if the button works of course, but you could have a
few, full stack tests to make sure).
This approach has some disadvantages though. The main one being you cannot
always separate the business requirements and the infrastructure.
A classic example is a RESTful web service. The business requirements are
full of GET, POST, DELETE, PUT, urls, application media types and JSON
payloads. Writing requirements in this language makes sense to everybody
involved including public consumers of the service and to abstract away the
http infrastructure seems wrong.
Of course, once I start running my tests against a deployed web app, I am
now back to square one regarding quantity of tests and how long they take
to run.
Any suggestions?
Thanks
Hi Rakesh, the trick I would use if I were you is to create my "business" object inside the servlet (or action class or whatever your preferred web framework asks you to use.) I would pass to this object the method, parameters, uri and whatever else it needs, and I would test that it returns the proper status code, attributes and body. There is a longer description of how to do it in this post by Misko Hevery Matteo
|
Testing business rules and not deploying the entire stack
Hi,
I'm building a new system and I want to get it 'right'.
What does right mean? It means I want to test my business rules against
just Java classes.
This approach has been advocated by Uncle Bob (I believe) and is very
seductive because I have worked on many projects where eventually, due to
running on a full stack, the test suite begins to slow down drastically.
The approach seems to be to express your business requirements in a
non-infrastructure related way. I can just about see this with a web app
with a html front end. Instead of saying 'click button Add User', you could
say 'select Add User' and call the underlying service call that the
controller was going to.
(You still don't know if the button works of course, but you could have a
few, full stack tests to make sure).
This approach has some disadvantages though. The main one being you cannot
always separate the business requirements and the infrastructure.
A classic example is a RESTful web service. The business requirements are
full of GET, POST, DELETE, PUT, urls, application media types and JSON
payloads. Writing requirements in this language makes sense to everybody
involved including public consumers of the service and to abstract away the
http infrastructure seems wrong.
Of course, once I start running my tests against a deployed web app, I am
now back to square one regarding quantity of tests and how long they take
to run.
Any suggestions?
Thanks
|
3/28/2013 2:13:55 PM
3/28/2013 2:13:55 PM
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
On Sun, Mar 24, 2013 at 11:40 AM, Michal Svoboda <pht@...> wrote: **
I think thats not such a bad approach. We use it quite a lot:
1. write dirty code of what you "want to do" (aka "spike")
2. observe the result
3. write automatic tests on anything that you verified manually
4. refactor/test-drive "mercilessly" and write new tests as you go
I think that the term for this is "Characteristic Tests", I was first introduced to it in Michael Feathers Work. but I'm not sure if it has a special section is his "Working with Legacy system": book or was it in a later video session i saw. A very useful technique in general, and should be an excellent idea in this case. Lior _
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
JeffGrigg wrote: For a pragmatic answer: Write the code. Run it. Observe the result.
Validate that the result is "reasonable." [...whatever the heck THAT
means!!!] Put the result in your test as an assertion.
Then you'll at least know when something changes. I think thats not such a bad approach. We use it quite a lot: 1. write dirty code of what you "want to do" (aka "spike") 2. observe the result 3. write automatic tests on anything that you verified manually 4. refactor/test-drive "mercilessly" and write new tests as you go
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
For a pragmatic answer: Write the code. Run it. Observe the result. Validate that the result is "reasonable." [...whatever the heck THAT means!!!] Put the result in your test as an assertion. Then you'll at least know when something changes. --- Avi Kessner <akessner@...> wrote:
... The math is too complicated for me to resolve easily. ...
|
ANN: My TDD Master Class is Available online (not free)
Hi Folks.
I hope you find this class useful - it is recorded live in my five days TDD
master class. focus is on .NET, but Java and C++ devs will find it helpful
as well.
the cost is about half the ticket to a normal class, with about 10 hours of
video demos and talks. based on my book "The Art of Unit Testing"
I have created 20 coupons for use in this mailing list: use coupon code
"tddlist" to get the course at $350 instead of $500 .
--
Thanks,
Roy Osherove
- @RoyOsherove
- Author of "The Art Of Unit
Testing"<>
)
- My blog for team leaders:
- My favorite keyboard shortcuts:
- +972-524-655388 (GMT+2)
|
Re: [TDD] Kata for test smells
Excellent you're just the man to write it. When you do I promise to shout from the roof tops (ok perhaps just twitter) singing your praises :-) Cheers Mark On Thu, Feb 21, 2013 at 4:14 PM, johantoutsimplement < martinsson.johan@...> wrote: **
Another thing you could do is try this exercise:
The tests that this problem drives you to write will have problems... that
you can then talk about.
Ok I'll keep that one in mind for the next TDD course.
I do think that that the community lacks a distilled written up kata about
just test smells that allows you to learn a lot about them in a shorter
time than it takes to build the problems yourself.
-- Cheers Mark Levison Agile Pain Relief Consulting <> | Writing <> Proud Sponsor of Agile Tour Gatineau Ottawa <> Nov 28, Toronto <> 26 and Montreal <> 24 [Non-text portions of this message have been removed]
|
Re: [TDD] Kata for test smells
Another thing you could do is try this exercise:
The tests that this problem drives you to write will have problems... that
you can then talk about.
Ok I'll keep that one in mind for the next TDD course. I do think that that the community lacks a distilled written up kata about just test smells that allows you to learn a lot about them in a shorter time than it takes to build the problems yourself.
|
Re: [TDD] Kata for test smells
Excellent resource. I can't use it directly as it's with java people but it gives me a good idea for places to look the next time. Apart from the expertise in test analysis in the videos.
toggle quoted message
Show quoted text
--- In testdrivendevelopment@..., Roy Osherove <roy@...> wrote:
I have a whole list here
and videos of test smells here
On Tue, Feb 19, 2013 at 10:23 PM, johantoutsimplement <
martinsson.johan@...> wrote:
**
Hi everyone,
I've been asked to teach test smells Thursday (!) and I'm looking for a
piece of test code that has a good number of them in order to use it for
identifying and then removing the test smells. I plan to make the learners
work on their proper test code but I'd like them to warm up on one or two
"distilled" examples first. And I'm thinking someone has already done that
before and might have it lying around somewhere.
I did find the introduction example in Meszaros book "xUnit Test Patterns"
which could do. But I was hoping for some choice.
--
Thanks,
Roy Osherove
- @RoyOsherove
- Author of "The Art Of Unit Testing" )
- My blog for team leaders:
- +972-524-655388 (GMT+2)
[Non-text portions of this message have been removed]
|
Re: [TDD] Kata for test smells
On Tue, Feb 19, 2013 at 10:23 PM, johantoutsimplement < martinsson.johan@...> wrote: Hi everyone,
I've been asked to teach test smells Thursday (!) and I'm looking for a
piece of test code that has a good number of them in order to use it for
identifying and then removing the test smells. I plan to make the learners
work on their proper test code but I'd like them to warm up on one or two
"distilled" examples first. And I'm thinking someone has already done that
before and might have it lying around somewhere.
I did find the introduction example in Meszaros book "xUnit Test Patterns"
which could do. But I was hoping for some choice.
There are a number of simple examples of how difficulties in the test drive a change in the code in Mauricio Aniche's book. Unfortunately this book is only available in Portuguese... Another thing you could do is try this exercise: The tests that this problem drives you to write will have problems... that you can then talk about. Matteo
|
Re: [TDD] Kata for test smells
I have a whole list here and videos of test smells here On Tue, Feb 19, 2013 at 10:23 PM, johantoutsimplement < martinsson.johan@...> wrote: **
Hi everyone,
I've been asked to teach test smells Thursday (!) and I'm looking for a
piece of test code that has a good number of them in order to use it for
identifying and then removing the test smells. I plan to make the learners
work on their proper test code but I'd like them to warm up on one or two
"distilled" examples first. And I'm thinking someone has already done that
before and might have it lying around somewhere.
I did find the introduction example in Meszaros book "xUnit Test Patterns"
which could do. But I was hoping for some choice.
-- Thanks, Roy Osherove - @RoyOsherove - Author of "The Art Of Unit Testing" ) - My blog for team leaders: - +972-524-655388 (GMT+2) [Non-text portions of this message have been removed]
|
Re: [TDD] Kata for test smells
If you google smelly code on this list you will find I asked this question a few months ago and got some good advice. If that doesn't help ping me offline. Cheers Mark On Tue, Feb 19, 2013 at 4:23 PM, johantoutsimplement < martinsson.johan@...> wrote: **
Hi everyone,
I've been asked to teach test smells Thursday (!) and I'm looking for a
piece of test code that has a good number of them in order to use it for
identifying and then removing the test smells. I plan to make the learners
work on their proper test code but I'd like them to warm up on one or two
"distilled" examples first. And I'm thinking someone has already done that
before and might have it lying around somewhere.
I did find the introduction example in Meszaros book "xUnit Test Patterns"
which could do. But I was hoping for some choice.
-- Cheers Mark Levison Agile Pain Relief Consulting <> | Writing <> Proud Sponsor of Agile Tour Gatineau Ottawa <> Nov 28, Toronto <> 26 and Montreal <> 24 [Non-text portions of this message have been removed]
|
Hi everyone,
I've been asked to teach test smells Thursday (!) and I'm looking for a piece of test code that has a good number of them in order to use it for identifying and then removing the test smells. I plan to make the learners work on their proper test code but I'd like them to warm up on one or two "distilled" examples first. And I'm thinking someone has already done that before and might have it lying around somewhere.
I did find the introduction example in Meszaros book "xUnit Test Patterns" which could do. But I was hoping for some choice.
|
