Repeat TDD Unit Tests for your Integration Test Suite?

[Dave Schinkel]

So I've gotten the team into TDD.  We may no be perfect in terms of creating good tests yet but they are certainly helping and we are definitely writing tests first.

So for example we've built a new Payment REST Service via TDD.  So naturally we have all these unit tests and so far they really serve us well and watch our back when we code.  It's just great.

The Payment Service just provides a central abstraction for all our other apps to call in order to make transactions against various payment providers that we use.  The payment service is more of a pass-through but we still do need a "service" layer, it's not redundant just for some information here in case you're curious.  Anyway, the payment service makes calls to logic in our business layer that we've built via TDD for this service originally.

Now I also have an Integration Unit Test project for our PaymentService.  These unit tests will be tests against our REST Payment service. 

My question is, should I be repeating the same unit tests essentially in our integration test suite that we basically have in our regular Unit Tests (non-integration tests) suite for our Service?  This is a Payment REST Service we've architect just for background info.  What makes them integration tests is that the tests will be making calls through WSDL (yea I know gross..), or from C# Models to Serialized JSON to our REST endpoints, or later we'll also have some JavaScript unit tests making calls to our REST endpoints as well.

part of me says yes, you want a set of integration tests that YES do test basically are kinda the same unit tests that we have in our business layer already as a result of TDD and I feel it's NOT duplication but then again maybe it is?  I've been told it's not.  Just because the service is kinda a pass through and light, the same calls that we essentially have built unit tests for in the business layer could fail for other unexpected reasons, you just never know.

[Andreas Schaefer]

I'd say unit test the correct pass through behaviour of each service method. have much fewer integration tests that also consider business logic state / behaviour

[Andreas Schaefer]

btw: what do you think makes your services RESTful, what makes them comply to the REST constraints?
WSDL and REST don't go together imho.

[Zachary Kessin]

I think the question you need to ask is are the tests providing value for your team? If the tests are providing some sort of value then do it. But don't write tests if the only reason is to meet some on paper coverage goal or the like. There are some things that are better done with an integration test and other things that are better done with a unit test. (And of course you can get fancy and do stuff like property based testing)

I spent this morning writing some property based integration tests for the ChicagoBoss Framwork's Postgresql Driver, seems much more solid now too.
 
--Zach

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

[Andreas Schaefer]

On Thursday, January 23, 2014 2:15:53 PM UTC+1, Zachary Kessin wrote:

I think the question you need to ask is are the tests providing value for your team? If the tests are providing some sort of value then do it. But don't write tests if the only reason is to meet some on paper coverage goal or the like.

full ack! I too do think that the main reason for testing should be for the team to have confidence in their code base in the first place .. opposed to having the need to meet a minimum level of coverage. A dev should feel safe when doing refactorings. If the confidence has proven wrong at some point then sure the tests would be improved :)

[Dave Schinkel]

What do you mean property based tests, are you saying you're unit testing your class properties?  you shouldn't be doing that...it's unnecessary.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

[Dave Schinkel]

If you are a true TDD shop, I agree with Andreas.  We decided to have both unit tests and integration tests for our apps period as they back us and I've seen it benefit...both kinds of tests.

[Sebastian Gozin]

Are we really talking repeating the same tests here? Or simply that there may be overlap?
Overlap is expected to some degree I think.

Certainly when we also add things like ATTD testing to the mix. It's all about the audience for those tests.

[Zachary Kessin]

Property Based Testing (PBT) also called "QuickCheck" was something invented by the Haskell folks a while back, it has since moved into the Erlang and Clojure worlds (and probably other places). The idea is that instead of giving your test a specific example to test you let the computer randomly generate a large number (usually 100) of examples until it finds one that does not work. It will then shrink that example to the simplest case that will still generate that error.

So lets say that you want to test a function to reverse a list, you might decide to express the property like this one:


prop_reverse() ->
    ?FORALL(List,
            list(integer()),
            begin
                List =:= reverse(reverse(List))
            end).

When you run this it will generate 100 lists of integers and ensure that for all lists that reversing it twice will always return the original list.

Or a more recent example that I did was that I wanted to ensure that a specific function would always do the correct thing when looking up an item in a dictionary where the item was not present, ended up with this test, I generate a dictionary, and a key, ensure that the key is not present, then query my function on the dictionary to ensure that it returns the empty list

prop_make_id_watchers_null() ->                                                                                                                                                                          
    ?FORALL({AttrWatchers0, Module},                                                                                                                                                                     
            {dict(), binary()},                                                                                                                                                                          
            ?IMPLIES((not (dict:is_key(Module, AttrWatchers0))),                                                                                                                                         
                     begin                                                                                                                                                                               
                         State = #state{id_attr_watchers=AttrWatchers0},                                                                                                                                 
                         [] =:= boss_news_controller:make_id_watchers(Module,State )                                                                                                                     
                     end)).                                                                                                                                                                              
                           

This podcast will explain more http://mostlyerlang.com/2014/01/20/288/

--Zach

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.

[Andreas Schaefer]

On Thursday, January 23, 2014 5:36:22 PM UTC+1, Sebastian Gozin wrote:

Are we really talking repeating the same tests here? Or simply that there may be overlap?

if the mentioned webService tests are unit tests where the businessLogic .. and actually all other components involved in the test .. gets replaced by test doubles and the behaviour gets validated then that'd be ok. But as he wrote about integration tests probably the businessLogic production code is used.

I'd say unit test all the webService methods, integration test some of 'em. If you'd integration test all of 'em, then they'd be somehow repeating tests. If you in addition leave out the webService unit tests, that'd be rather disadvantageous (imho).

[Andreas Schaefer]

On Thursday, January 23, 2014 5:03:24 PM UTC+1, Dave Schinkel wrote:

What do you mean property based tests, are you saying you're unit testing your class properties?  you shouldn't be doing that...it's unnecessary.

It actually might not, if you e.g. are implementing a stereotypical architecture (http://cqrs.wordpress.com/documents/a-stereotypical-architecture/). Then you actually had to test the state of all properties after the execution of a specific UseCase. Greg Young explains it in this video: https://www.youtube.com/watch?v=KXqrBySgX-s

[Rusi Filipov]

My question is, should I be repeating the same unit tests essentially in our integration test suite that we basically have in our regular Unit Tests (non-integration tests) suite for our Service?  This is a Payment REST Service we've architect just for background info.  What makes them integration tests is that the tests will be making calls through WSDL

First, I didn't understand your question, because integration tests usually have a bigger scope than unit tests. So they usually test on a higher level operation and don't focus on the small parts like unit tests do. That usually means that if a multiple classes collaborate in order to achieve a goal (a high-level business operation), then each of these classes would be unit-tested by one test class full of unit test cases, and the whole high-level operation would be integraton-tested by another class containing some integration test cases. But your words make me think that your unit tests don't isolate and focus on separate classes, but test the whole component through it's programmatic API. Can it be the case?

[Uncle Bob]

Integration tests are not business rule tests, they are plumbing tests.  In an integration test you are testing that the components of the system dance well together, you are not exhaustively testing every nook and cranny of every business rule.  Because of this there is a very real need to continue to run the exhaustive unit tests in conjunction with the much sparser integration tests. 

Sometimes, if the integration tests are running long, it is useful to replace the business rules with stubs so that the database and processing times are reduced.  If you do this, you'll want to run a small fraction of the integration tests with the real business rules just to make sure there aren't any compatibility issues.  

[Dave Schinkel]

thanks, I now finally realize this after getting some tests up and running.