.Net C# ConsoleApp
I am unfamiliar with Console AppsAnd to make matters worse this app pulls our data and sends it to a vendor api and there is no dev version in placeI have a solution that in the properties it starts in MyConsoleAppNameConsoleLauncher
Inside that I see only one cs file called Program.cs.
In Program.cs there is a Main void.
Can I assume that is where this thing kicks off at?
I have now replicated the procedures and data in a dev database and am pointing to that BUT I want to intercept and exit the sub BEFORE it selds any data to the vendor.
ASKER
ste5an
Well... I need to test the pull of my data
And
NOT send it to them
So jus comment that section out?
Well... I need to test the pull of my data
And
NOT send it to them
So jus comment that section out?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
![Avatar of Alex [***Alex140181***]](https://filedb.experts-exchange.com/files/public/2022/11/13/8257e912-ee3c-4a93-9df0-fe9a8a1515cf.jpeg){kind=small}
For rudimentary testing purpose, you may comment out those calls, sure, but you'd have to find them first ;-)
It's way beyond "best practice" and you should look out for other patterns, like ste5an already hints at ;-)
It's way beyond "best practice" and you should look out for other patterns, like ste5an already hints at ;-)
No, Cause commenting it out, means that you test different code, than the later production code. This is a no-go.Way too general, sorry :-(
You're comparing apples with pears here... In terms of "real testing", I'd agree with you 1000%, but he just wants to "pre-check" before things get sent. IMHO, if this remains the one-and-only manual step to prove himself something, it's ok ;-)
I like truisms :)
In the actual case data crosses a system boundary. This system boundary needs protection. E.g. PowerShell defines a "mandatory" WhatIf parameter. So that you can test at any time what may happen. Here the same is needed.
Or take the case of a payment interface. Upstream testers won't be happy about made payments for testing.
Here you should watch the wonderful talk from Miško Hevery: Design Tech Talk Series Presents: OO Design for Testability and the similar The Clean Code Talks - Don't Look For Things!
Especially the second explains imho the two pillars concept. This what we want here. We want the code during construction time to create either a production or testing version. During run time we can step thru and see what happens.
In the actual case data crosses a system boundary. This system boundary needs protection. E.g. PowerShell defines a "mandatory" WhatIf parameter. So that you can test at any time what may happen. Here the same is needed.
Or take the case of a payment interface. Upstream testers won't be happy about made payments for testing.
Here you should watch the wonderful talk from Miško Hevery: Design Tech Talk Series Presents: OO Design for Testability and the similar The Clean Code Talks - Don't Look For Things!
Especially the second explains imho the two pillars concept. This what we want here. We want the code during construction time to create either a production or testing version. During run time we can step thru and see what happens.
Truisms? Don't be silly ;-)
I even haven't started to be silly right now.. Beware!)
lol, sure
2) No. You don't want to intercept or exit a "sub" before something happens. You want to restructure the code, so that preparing the call and executing and a possible post-processing are separate steps. thus separate methods. Then you call the steps you want. And you want to do this in a separate class for better code reuse, e.g. for an additional unit test project.
In terms of OO: you should look into the template or strategy pattern as well as the factory method pattern.