Soap UI tool generates log file after each execution. To know the reason for the failure, we go through log file. Log file does not have a proper stack trace with filename, methodname, line number etc for the failed test rather the generic reason for the failure of the test step. So, we have to debug the application for the failed method and this process takes a good amount of time to debug and find the bug. Hope it clarifies the question.
In this case, I agree with Pete. You're not going to be able to write code to automatically find which check in caused the problem. You could even have multiple problems.
You have two possible paths here. The first is to debug the code and do what you've been doing. This is, obviously, time consuming and reactionary.
The other is to implement a check in process where the code is tested before you allow it to be checked in. It sounds like you've got people "breaking the build" on just about every check in. That's not tolerable and must be prevented. Yeah, it sounds like it's more time to do this. It is but instead of spending that time on finding and fixing the bug you're spending it on preventing the bugs and improving the quality of the code.
If I were in your team, I would suggest that you would be better off with a comprehensive CI process with decent unit tests and pre-flight check ins to ensure that you don't regularly commit broken code.It's better to prevent problems than look to apportion blame.
It seems to me that you could tackle this in one of two ways: (1) Finer granularity on your build process. Somebody else already suggested a full-blown CI solution, but you could (I suppose) build say 4 times per day, which would dice-up the problem and presumably help; (2) Semi-automate the debug process by correlating changed modules with locations where errors are arising.
Option 1 requires that you can get those merges done more often and turn the build handle. Option 2 strikes me as a good thing to do anyway, but whether it adds much value will obviously depend on how "orthogonal" the changes are that people are making to the code: if many are making changes in the same few files then it's not really going to work.
By "finer granularity" I meant only that you could build more frequently. For example if currently you build at (say) midnight each day after everybody has finished work, then if Module "X" was changed 3 times and now fails to compile you've got to figure out which change caused it to fail. If, however, you'd done several builds during the day (e.g. every 2 hours) then you have more chance of discovering a broken build for which only one checkin has been done.
Taking this to an extreme you end up with CI = Continuous Integration in which typically there'll be a gate on the checkin process with some mandatory regression tests needing to be passed before checkin can be done. There are lots of ways to implement this in practice: you could allow checkin but advance a stable label only as each checkin is built and validated. In the ideal world CI should ensure that your code always builds. However this is a big topic which is why I suggested only a small change to your existing process rather than a fundamental change of strategy.
You're first going to have to describe what you mean by "autocorrect". If you're talking about a spell check (which is what I think of when I hear "autocorrect") there's no such thing in Visual Studio.
Visual Studio has Intellisense, which will suggest names of existing objects in your code to make things easier and faster to type.
you don't get it. as far as i remember, in VS 2008 / 2015 when i type, for example, "Move" and the suggestion will pop up (like Moveblablabla, etc) BUT if i continuing type "(" (WITHOUT have to press Esc) it will become:
Moveblablabla() //this is when i say, it force you use its suggestion
Oh I get it. I've understood for a while now. Every version of VS with Intellisense has behaved the way you're describing, though, each language editor has it's options set differently from the others by default.
I already told you what you're going to have to do. Tools/Options/Text Editor/... and start exploring the options.