Reply to: Testing Question - What do you call this?

[SpontaneousOrder]

Well it may not be PC for this thread but I personally like to call such sandpits errm sandpits
Or you could go for POC (Proof of Concept).

It's not a PoC.

[SpontaneousOrder]

Generally:

Stub describes a test double that returns canned responses.

Mocks describe those which can be dynamically configured to produce desired responses & give the ability to verify interactions.

Fakes pretend to be real functioning systems/components.



People often refer to spies in reference to things which act like stubs, but save the invocations for later inspection.

[Contreras]

To me a stub is where you insert some kind of class or mock that pretends to call a service (like a card acquirer) but actually just returns some data that the program can continue with.

Same here. I've never heard it applied to simulating a system as a whole, until now.

If that makes me a crap code monkey then so be it.

[MrMarkyMark]

Well it may not be PC for this thread but I personally like to call such sandpits errm sandpits
Or you could go for POC (Proof of Concept).

So last year Dahliing...

"Stub" has more of a roguish, Hipster, charm about it

[DallasDad]

You are a developing a system which needs to interface to another system. You don't however want to use a test version of the second system, so you build a dummy that has limited functionality sufficient to permit you to do primary system testing.

Now the question is what do you call the dummy system?

Well it may not be PC for this thread but I personally like to call such sandpits errm sandpits
Or you could go for POC (Proof of Concept).

[MrMarkyMark]

Not really, you mainly use stubs on dev and sometimes system test, not all interfaces you work with have test environments themselves.

The stub just simulates a happy path call so you can check that was should be returned by the live system is accepted into your new system.

If you have never come across a stub before you are either not a tester, or a crap code monkey

Certainly not a tester or a crap code monkey, LOL, but, at least I do know what I'm talking about.

I have seen plenty of integration projects go completely wrong, in the past, especially large ERP systems. In fact I saw one international news agency almost go bust, in the early 2000's, was costing them £1m, per day.
I have, also, seen systems where core functionality, like order processing or invoicing does not work (!), as the interfaces were not fully integration tested.

Obviously, this type of approach, stub, or whatever you want to call it, was used inappropriately, at the integration stage, you will always face a series of risks using it.

Quantifying those business critical risks, presenting them to the business, getting extra budget, pushing back, is part and parcel of what an experienced contractor does.
To be clear, I'm not talking about end to end testing of everything, either, that would be ludicrous.

In addition, correcting mistakes, in core functionality, after the event, costs a lot more than identifying it and fixing it earlier!
Clever thinking saves businesses money, it doesn't cost them it.

HTH

[LondonManc]

If the acceptance criteria of your SIT is full end to end testing that god help your project budgets!

Where the hell did I say that?
You're now making stuff up to cover up for your overly-aggressive salvo at me an then misreading or misunderstanding what I'd said about acceptance criteria. The acceptance criteria for something leaving SIT and moving to UAT is very different to the acceptance criteria for full end to end testing.

[SimonMac]

I talked about acceptance criteria, not acceptance testing. Who interviewed you, Bee?

To pass SIT, it needs to meet certain acceptance criteria.

I'd try and dumb it down further but my nephew's crayons aren't available at the moment.

If the acceptance criteria of your SIT is full end to end testing that god help your project budgets!

[LondonManc]

What time does the second half start?

If numbnuts has learned to read over lunch, match should be abandoned at half time.

[stek]

What time does the second half start?

[LondonManc]

You state the OP is looking at integration test but you start prattling on about acceptance testing. Dumbass much?

I talked about acceptance criteria, not acceptance testing. Who interviewed you, Bee?

To pass SIT, it needs to meet certain acceptance criteria.

I'd try and dumb it down further but my nephew's crayons aren't available at the moment.

[Cirrus]

And so on ad infinitum

I agree it's always a bit dangerous when you start talking about simulating things. I remember reading a book on Test Automation which of course started talking about once you build test systems to drive real systems to test them, you are now into the territory of testing the test system and potentially writing automated regression tests of the automated tester.

Then you might want to test the automated test system that tests the automated test system...

To me a stub is where you insert some kind of class or mock that pretends to call a service (like a card acquirer) but actually just returns some data that the program can continue with. There's not a world of difference, I can see, in instead calling a running simulator service and getting back the same test data from that, but it just seems more comforting. And maybe more re-usable (less sensitive to particular platforms, environments etc.)

[SimonMac]

Way to judge someone.

The OP is looking at a system integration test.
The first thing I'd look at is acceptance criteria, which would then drive what functionality of the ancilliary system is needed in the cut down version. It's a barebones effort to cover that functionality that is required. How easy it is to create such a thing is a guess to anyone not involved in the project, yet you're prattling on about PCI card acceptances. Sockie much?

You state the OP is looking at integration test but you start prattling on about acceptance testing. Dumbass much?

[LondonManc]

When I was on a PCI project you can't put though real credit cards to test payment, most merchant services won't let you connect a dev/integration test environment to their systems to use their test end point, what do you do?

As its not UAT you don't need the rigour of testing against the live endpoint so you stub it, if you think this is "rolling a turd in glitter and hoping it shines" I really hope you are just a support bod and not let anywhere near a development project

Way to judge someone.

The OP is looking at a system integration test.
The first thing I'd look at is acceptance criteria, which would then drive what functionality of the ancilliary system is needed in the cut down version. It's a barebones effort to cover that functionality that is required. How easy it is to create such a thing is a guess to anyone not involved in the project, yet you're prattling on about PCI card acceptances. Sockie much?

[mudskipper]

stub++