Is Contract testing necessary when both consumer and provider are developed by the same company in different scrum teams ?
Yes, definitely. Contract testing is particularly useful when you rely on an 'external' service, where by external I mean any service that is not under your direct control, including the case you mentioned. Here is an interesting article from Martin Fowler.
Short answer: no, contract testing isn't necessary in any situation, the same as unit testing.
Long answer: Not having testing greatly reduces your confidence as a developer to deploy without breaking anything. Unit testing is good for testing an individual function, while contract testing is good at figuring if your changes will affect any consumers of the data you provide. The consumers of your data could be anyone, it could be someone across the room from you, a client external of the company or even yourself. The whole point is to try to segment and simplify the development process so that problems are caught earlier on. It also has the added benefit that you don't need to run the data producer locally just to have the consumer working while developing, which is definitely a great bonus when the consumer doesn't (or can't) have access provider code, like an external client.
These tools are meant to make your life as a developer simpler and easier to manage, Pact strives to accomplish this in your workflow and to prevent issues from happening in production and giving the developer a quicker feedback loop of potential issues.
The team that wrote Pact in the first place was responsible for both ends of the integration, and they still found contract testing valuable. Just because you're developing both sides now, doesn't mean that you will continue to be responsible for both sides in the future. Contract tests will ensure that changes made by future developers will not break anything.
Related
Why CDCT is not working for most cases in real life? The concept and tools have been selled by architects for quite a few years especially in micro-service architect, or in multi-modules complex system, there are a lot of pains for integration testings, but why CDCC is not implemented everywhere?
I heard the concept and tools about CDCT (consumer-driven contract test) about three years ago, I used to do some research in our enterprise software (one of the most complex SaaS softwares in the world, 15 years-old, developed by more than a thousand engineers) and discuss it with our chief arch about two years ago. It looks promising that we are supposed to be able to find a real case to implement it via a proper tool like pact, between two proper teams who have pain point so does the motivation, why not? The concept absolutely makes a lot of sense, the problem it aimed to solve is a very common one (who doesn't have an integration broken by another team?), everything looks perfect and I even added into my yearly goal.
I failed, I was young and simple, it didn't work out, hopeless.
Today I heard a same failure from another team, and no surprise they have same reason that’s why I think it might be write it down to as a reminder and useful (probably) knowledge to share.
The reason is high adoption cost including mindset change. CDCT is not a tool (you can use a tool like pact to better implement it), it's not even a methodology only, it's a new mindset to tell people how to work together.
Yes it’s aimed to solve the problem between multiple systems/modules, but it is more to create a new mindset which needs the two groups of people to accept: firstly a contract is needed (vesus no contract is needed), secondly consumer is the driver of the contract (vesus provider is the driver of integration).
Here is the tricky part, from consumer perspective, what needs to be done for integration point(s):
Before CDCT: 1. find an API and use it. 2. when it breaks, blame provider
After CDCT: 1. find an API 2. drive: find provider, meet with provider, negotiate with provider, come up a contract, repeat this if there is gap, signoff the contract and save it. 3. Write testing, ask provider to review the testing, ask provider to put your testing into their pipeline. Figure out how to make sure provider always make your testing pass rather than comment them out before they release a new version of service.
I can understand why consumer may not really want this, or why they want the result but hesitate to pay the cost first.
So when CDCT implementation will be successful? I think there might be two conditions:
The consumer's business is too important to be broken (say accounting), they have no choice but do everything can safeguard the dependency. However, in such a case the better idea is to remove the dependency, or adding duplication and fail-over mechinsim, testing is still the last choice.
The provider and consumer are working very closely so the mindset and setup cost will be mininum, unfortunately contract testing might not be needed in this case, because the teams are working very closely.
Regards,
Emil
Presently i'm working as web developper in a small company and i'm in charge to create a new web software to manage our business.
We cannot hire new developpers yet and we must deliver a first version as soon as posible.
In this context, i'm thinking about microservices architecture and i don't know if we should spend some time and resources to start our project with this kind of architecture.
Somebody has some experience about this subject?
Thanks,
We're a small team (<10 persons) and are using a microservices architecture and are getting a lot of benefits of it. But to be successful with a microservices approach you need to meet a bunch of prerequisites. (See http://martinfowler.com/bliki/MicroservicePrerequisites.html) So if you need to deliver fast and you're not yet into continuous delivery and DEVOPS, I would stay away from it.
My 2c
I think your approach towards microservices appeals to be misleading. I also understand your apprehensions towards microservices.
But, decision to chose microservices strategy should not be directly dependent on the developer base. In deed it is highly dependent on the current and future business needs of your organization. In fact if you do not anticipate any major growth or expansion of your IT services and its complexity around the systems, then you could stick to monolithic pattern.
Irrespective of small/big enterprise, one key factor for microservices strategy is its growing number of services.
Intro:
I'm working for a contractor company. We're making SW for different corporate clients, each with their own rules, SW standards etc.
Problem:
The result is, that we are using several bug-tracking systems. The amount of tickets flow is relatively big and the SLA are deadly sometimes. The main problem is, that we are keeping track of these tickets in our own BT (currently Mantis) but we're also communicating with clients in theirs BT. But as it is, two many channels of communication are making too much information noise.
Solution, progress:
Actual solution is an employee having responsibility for synchronizing the streams and keeping track of the SLA and many other things. It's consuming quite a large part of his time (cca 70%) that can be spend on something more valuable. The other thing is, that he is not fast enough and sometimes the sync is not really synced. Some parts of the comments are left only on one system, some are lost completely. (And don't start me at holidays or sickness, that's where the fun begins)
Question:
How to automate this process: aggregating tasks, watching SLA, notifying the right people etc. partially or all together?
Thank you, for your answers.
You need something like Zapier. It can map different applications and synchronize data between them. It works simply:
You create zap (for example between redmine and teamwork).
You configure mapping (how items/attributes in redmine maps to items/attributes in teamwork)
You generate access tokens in both systems and write them to zap.
Zapier makes regular synchronization between redmine and teamwork.
But mantis is not yet supported by Zapier. If all/most of your clients BT are in Zapier's apps list, you may move your own BT to another platform or make a request to Zapier for mantis support.
Another way is develop your own synchronization service that will connect to all client's BTs as each employee using login/password/token and download updates to your own BT. It is hard way and this solution requires continious development to support actual virsions of client's BTs.
You can have a look a Slack : https://slack.com/
It's a great tools for group conversations
Talk, share, and make decisions in open channels across your team, in
private groups for sensitive matters, or use direct messages
one-to-one.
you can have a lot of integrations tools, and you can use Zapier https://zapier.com/ with it to programm triggers.
With differents channels you can notifying the right people partially or all together in group conversation :)
The obvious answer is to create integrations between all of the various BT's. Without knowing what those are, it's hard to say if that's entirely possible. Most modern BTs have an API and support integrations. Some, especially more desktop based ones, don't. For those you probably have to monitor a database directly.
Zapier, as someone already suggested, is a great tool for creating integrations and may already have some of the ones yo need available. I love Slack and it has an API, but messages are basically just text and unless you want to do some kind of delimiting when you post messages to its API, it probably isn't going to work.
I'm not sure what budget is, but it will cost resources to create the integrations. I'd suggest that you hire someone to simply manage these. Someone who's sole responsibility is to cross-populate the internal and the external bug tracking system and track the progress in each. All you really need is someone with good attention to detail for this, they don't have to be a developer. This should be more cost effective than using developer resources on this.
The other alternative is simply to stop. If your requirements dictate that you use your clients' bug tracking software for projects you do for them, just use their software and stop duplicating the effort. If you need some kind of central repository or something for managing work maybe just a simple table somewhere or spreadsheet with the client, the project, the issue number, the status and if possible a link to the issue in the client's BT. I understand the need and desire for centralizing this, but if it's stifling productivity, then the opportunity costs are too high IMO.
If you create an integration tool foe this, you will indeed have a very viable product. This is actually a pretty common problem.
I'm working on a new application at work, and a manager is really pushing the concept of a business rules management system (BRMS) and a workflow management system, and I'm trying to figure out the best way of integrating these types of tools.
With regard to these types of systems, I don't know what I don't know, so I'm trying to get other perspectives and information.
The thing the manager is looking for is the ability for business users to change business rules or process flows without the need for developer time (or with minimal developer time).
A BRMS is easier for me to understand when I think about how it would fit into code. It's pretty straightforward, and I can see how the logic could reside completely outside of an application. Since I haven't done much with these types of systems, I would appreciate any info on good products that integrate with .NET, or info on experiences. (We're looking at InRule, Blaze Advisor and ILOG Rules)
What I'm less sure of is the workflow part.
Workflow Foundation makes sense to me, as it's a known, defined workflow that's integrated into application code, but the manager isn't looking for a foundation, he wants a tool that lets business users define and update workflows. Any type of system that allows end users to dynamically create workflows makes less sense to me.
I was asked to look at WorkflowGen as an example of a workflow engine. To me, it looks like it's completely self-contained unless a developer writes .NET code to interface with back-end systems.
I can understand a workflow system that allows users to define specific, limited actions, like "e-mail so and so" and "require so and so to approve," but I have no idea how a workflow system that's supposed to dynamically define application flow can be integrated in to an application, or even how the more simplistic system I just described can display and update back-end data.
I'm pushing for use cases so I can better understand what my manger is looking for in terms of moving these types of logic outside of application code, but in the meantime, I'd appreciate any info anyone has on these types of systems. As I said, I don't know what I don't know, and our business users seem to think our new application should support these types of tools. I want to make sure I'm limiting our functionality due to my lack of knowledge.
Thanks for any information or advice.
If you work in .NET: .NET Workflow Foundation. It's complex, true, but it's free and has everything your manager asks for. Business rules part will require some getting used to, the workflow will need some initial investment in building your own "environment" but, when you look at all this from above, WF.NET still gives more than what others has to offer. InRule is a cheap product that can't really do much, Blaze is way too complex, way too expensive and not really for "non-programmers"; ILOG is, too, not for "business users".
I build web apps for a living.
An important but often painful process is client/user acceptance testing.
How do you manage this process?
i.e. How do you get them to test? Do you give them test scripts?
Do you give them a system to log bugs and change requests/feedback. How do you get the client to understand the difference between a bug and a feature change?
How go get clients to give you repeatable steps to create a bug/issue?
Any good web apps for managing this process (thinking a Basecamp like app would be very uesful for this)
Thanks,
Ed
Don't give them test scripts.
To me that invalidates the testing process to a large degree because if you're thinking up test cases your software probably handles them because you've thought of them.
The idea of good testing is that there is a level of independence in testing so you can't cater for known test cases and also the client is likely to think of scenarios that you won't, which is the whole idea.
But how do you motivate them? Well, honestly I'd be surprised if they weren't motivated. I've generally found that motivating them to comment on func specs, requirements and other preliminary documentation is a far tougher battle. By the time you get to testing, you've eliminated an important psychological hurdle in that the software is now "real".
How you handle this depends to a large extent on the nature of your relationship to the client. If you have a formal process with an agreed upon spec, you should really be saying that the client has a certain period to sign off and accept the software and inaction is implied acceptance.
If it's an internal client well then that's harder. It probably all comes down to who's driving the project? Who are the stakeholders? These are the people you need to motivate such activity.
Usually the best method that I've come across for client testing is having them send screenshots of the problem and some of the things they did to create it. By this point, most of the testing should have been done in house and the egregious bugs should be weeded out. Having a system that automatically emails that an error occurs lets me know they are testing and I get most of the gory details from the stacktrace in the email.