|
Based on all of your feedback and some additional search I have the following solution for me
I will return a Transaction-Object
struct TransactionResult {
double amountReturned;
EnumTransactionResult eReturn;
}
Some more info:
- I have no complicated scenarios as "Pending Transactions"
- Of course: I can overdraw the account upto an allowed value, which can be less than zero
- This fully fulfills my use-case
Thank you for your input. My question is fully answered
|
|
|
|
|
I cannot debug (set breakpoints,...) my UnitTests with NUnit3.
What works already
My Test-Dll's contain all the tests. They are executed and the result is displayed correctly in the output-window when I run them with the console-runner. So, the test-setup itself seems to be correct.
What I want:
I want to DEBUG my tests when they are executed with the console-runner and stop at breakpoints.
What I did so far:
=> I create a Dll, which contains the testcases/-fixtures.
=> I have set this Dll-Project as startup-project
=> At Properties | Debug of the Dll-Project I select the console-runner as"Start external Program"
and I add the command-line arguments ( my dll )
=> I set breakpoints in my test-code
=> I start a debug-session: The tests are executed, but not breakpoints are hit
It seems, I misunderstand some concept completely
|
|
|
|
|
Have you copied your pdb files in as well?
This space for rent
|
|
|
|
|
yes, the complete dll-bunch is in one single directory. Together with all pdb's
|
|
|
|
|
|
It does not help. I was already aware of this 
But thank you very much ! ! !
I searched a lot of links, but all I found is referencing quite old versions of Nunit.
I use NUnit.Console-3.7.0.
All of my tests are executed "perfectly". The only problem is: Breakpoints are not hit
|
|
|
|
|
Maybe try a newer version (3.9):
Downloads
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
hai
am cyrrently working on a file monitoring system in c# that records all events in log format, with a command to dump logs as .txt files.
my question is, is the a code i could use to dump these log files into a file, save them at a specific time in the day.
say while its monitoring, it automatically saves the logs in a file at 23:59 everyday.
while monitoring a particular folder.
given there is a path in which to save.
|
|
|
|
|
|
You can either use a Timer, or check the time whenever you write a log record. Alternatively use a separate application the gets scheduled to run at a fixed time every day.
|
|
|
|
|
Why aren't you just writing the events to the log? If you're keeping this stuff in memory and writing it to a log later, you run the risk of running out of memory before you write the log!
|
|
|
|
|
We need to bring a Word document into focus and then paste text into the document at the current cursor location. We know the name of the Word document. Unfortunately Word only has one instance and one main window, which means that I cannot simply locate the window, bring it into focusand paste the data. Is there a way to do this from C#?
|
|
|
|
|
I hate applications that steal focus, as many other users do.
Do you need to show the Word-application, or would it suffice if you can embed Word in your application and push that to the foreground?
Inserting text into a document would be rather simple, as a word-document is a zipped collection of files you can read with notepad.
Do you want to replace text at a certain pre-determined position, or at the cursor? If the latter, you may be better of writing a Word-adding that doesn't steal focus.
Many questions here 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks for the response. Our requirements are that the user must be able to configure our system such that data from a reader is pasted into a user chosen application. Because this is generic, the way we do it is to bring the app into focus and then paste the data. For images we use the clipboard.
This is not intended to run on someone's work PC, rather it is an automated system, and giving an app focus is desirable as the operator can see the read data.
We wish to post into the cursor position in the target document.
|
|
|
|
|
In that case you would want to get a list of processes and enumerate its windows. You'd probably need some WinAPI to identify the correct window.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I already do that. Unfortunately Word only has one main window. I've tried to enumerate the child windows but that does not work, it only locates the topmost. If you run up two documents, then look in Task Manager, you'll see what I mean: one process and one window.
|
|
|
|
|
That's the only way I know to get the Windows that are created by the process.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
[EDIT]
I agree with Eddy Vluggen that you don't need to keep focus to the document/application to be able to paste piece od text. You need to refer to the document you want to use:
document = InstanceOfWord.Documents["ShortDocumentName.docx"];
document.Selection.PasteSpecial();
document = InstanceOfWord.Documents("ShortDocumentName.docx")
document.Selection.PasteSpecial()
More at MSDN: How to: Programmatically Insert Text into Word Documents
But, if a requirement is to keep focus, there's good news: there's buit-in method called: Document.Activate Method (Word)
InstanceOfWord.Documents["ShortDocumentName.docx"].Activate;
InstanceOfWord.Documents("ShortDocumentName.docx").Activate
|
|
|
|
|
I used to unit test private methods, then some people advised me not to do so...
What do you think? should I unit test only public methods or private methods as well?
|
|
|
|
|
This is one of those questions that can end up in semi-religious wars with people wanting to burn the heretics who don't do things "their way". If you are part of a team and the standard is to just test public implementations, then you just test public implementations. If that team insists on unit testing everything, then test the private methods as well.
I have to admit that I prefer tests that only test the public methods. Basically, if you have a private method that you can't get to somehow via your public methods then either that code is "dead code", or you have a serious problem with your architecture and are relying on reflection in the main codebase to get at this code and run it. Thing is, if you follow SOLID principals, no single part of your codebase should be that large that you can't adequately cover the private methods via the public methods/properties.
This space for rent
|
|
|
|
|
Very pragmatic! Spot on. 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Don't you think that testing only the public methods creates a problem?
When a test of a public method fails, it is not clear where it fails. Is it in the public method called directly by the test, or in a private method called by the public method?
|
|
|
|
|
Member 13624012 wrote: Don't you think that testing only the public methods creates a problem?
No I don't.Member 13624012 wrote: When a test of a public method fails, it is not clear where it fails. Is it in the public method called directly by the test, or in a private method called by the public method?
Where it occurs is immaterial; the important thing is that the test failed. You have a predictable input (or set of inputs) going into a method that cause it to fail; debugging through the failure is a simple enough task that it doesn't matter.
To put things into perspective; if you have to debug private methods, you are introducing a coupling in that your test has to know how the methods behave and recreate the conditions necessary immediately before calling the method, so you need to take things like state into account. What you have done here is make it harder to change the working of code because any change will probably necessitate changing the tests as well. This is testing the "how" of the code. If you are testing public methods, you are more likely to be testing the behaviour of the code, so the inner logic has much more room to change.
An example might suffice here. Suppose I have a piece of code that writes to a log and returns a value to indicate that the log was successfully updated, and I have a test to ensure I get that value back; now, if I just test the public call of WriteToLog, I can ignore what happens inside and check the return value to ensure I get the expected one back - I'm ignoring the fact that, initially, I was logging to the file system (the how) and am now logging to a database. As long as I get that value back, I know that the particular piece of code behaved itself. This becomes much more important when you consider that I build up systems organically, so my initial internals would probably be a dummy logger which I would then build out and replace.
This space for rent
|
|
|
|
|
I would say that you have to test both, sorry.
Just to prevent you from hiding complexity in the private members and having each public member point to something private.
Bad of trust? Yes, but also a fan of proving that stuff works as intended. Too much proof is never a negative, is it?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Yes, I agree with you. I think that there's no such thing as too many unit tests!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
