Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Suppose that you are writing or maintaining a piece of code that uses some API that you are not 100% familiar with.
How do you decide whether to read the documentation of a certain call target, and how much time to spend reading it? How do you decide not to read it?
(Let's assume you can read it by opening the HTML documentation, inspecting the source code, or using the hover mechanism in the IDE).
Ideally you should read all of it, but we know that's a pain in the... you know. What I normally do on those cases (and I did that a lot while I worked as a freelancer) is weight some factors and depending on the result, I read the docs.
Factors that tell me I shouldn't read the docs:
What the function does is easy to guess from the name.
It isn't relevant to the code I'm maintaining: for example, you are checking how some code deletes files, and you have some function that obviously does some UI update. You don't care about that for now.
If debugging: the function didn't change the program state in a way meaningful to the task at hand. As before, you don't want to learn what SetOverlayIcon does, if you are debugging the deletion code because it's dying with a file system error.
The API is just a special case of an API you already know and you can guess what the special case is, and what the special arguments (if any) do. For example, let's say you have WriteToFile(string filename) and WriteToFile(string filename, boolean overwrite).
Of course, everything depends on the context, so even those rules have exceptions.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
This might sound a very vague question, but I am hoping to get some insight from all of you who can throw some ideas so that I can move in the right direction. I have ReadyAPI license and want to develop an automation framework around it. I can of course add assertions and create tests and everything within the tool, but I am wondering if there is a way I can build keyword or data driven framework around it so that I can have reusability, ease of use, adding assertions on the fly, execution via excel, or even adding assertions via excel (not sure). I am not sure if that's going to make creation of tests even more complex. Please provide your valuable inputs!
If you already have Ready API! then you probably don't need anything else. The licence is not cheap, so you'd have to consider if you really want to spend more money buying something from Mindtree. And, looking at their list of dependencies, there's always the danger of getting bogged down in the tooling and making them work together rather than doing actual work.
Why not start small and simple by doing some data-driven test cases using Excel or even a database as your source? I've used Excel to drive test cases and to populate assertions and not encountered any problems. For any customised behaviours, there's always Groovy to help. Then, once you've maxed out the capabilities of Ready API! look at something else.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm wondering if there's an accepted/idiomatic way of testing an unexpected behavior when working with external systems (such as databases). These are mostly cases within "if err != nil {...}", when normally the error just doesn't happen and you don't control it through the inputs.
One "right" way of doing that is probably defining an interface and a mock structure that would return error when you need it. But if I already have a significant amount of code that doesn't work with interfaces, bringing them just for the sake of testing a couple of scenarios seems tiresome.
So does anyone know and use different approaches? For example, in dynamic languages such as php and js a function/method behavior can be easily overridden with a mocking library or even manually, which is quite useful when writing tests.
Using interfaces and custom / mocked implementations for testing is the way to do this. If you want to test most of your code, it is worth making the switch now. If you don't want to test most of your code just a tiny part of it, then what's the point of even bothering with the test? They won't ensure you of anything, on the contrary, they will give you the–false–illusion that "everything" is fine.
If you don't want to use and mock interfaces, another way would be to mock the database server itself, but let's face it, it would be even more work.
Just use interfaces. It's never too late to refactor. It is something always worth doing on the long run.
Also note that you can do this "switch" gradually. Just create an interface that contains the functionality used by the code you want to test. You don't need to "touch" the rest of your code. Change the testable code to use the interface, which then you can mock in your tests. This is easy in Go.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I don't know where to start with this. If there is a way, all I need is an object name or collection name, so I can look up the feature on Microsoft's site, and go from there. But, searching there directly didn't turn anything up.
You're probably looking for the VBE Extensibility Library.
However note that depending on what you're actually trying to do ("modify other VBA code"), it may be very hard, if not impossible to implement.
The library will let you iterate modules, locate their members, pull the actual code into strings (from entire modules or just a given procedure)... but that's as granular as it gets.
If you're trying to do anything that requires understanding of the code's semantics, the VBIDE API won't be enough: you need a lexer and a parser for that... and I've yet to see a successful lexer/parser for VBA, written in VBA.
Good luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am documenting a small itcl project. Due to shortcomings in itcl support in doxygen, and the fact that Ruff! does not support itcl, I am left with NaturalDocs and RoboDoc as the leading candidates. However, I don't want to pick an unsupported system, and was wondering which is going to be there in the long term?
What will be there in the long term? Who knows! It depends on how much people use it, really, as with all open source code systems. It should be noted that both the tools you refer to are really slow developing at this point: they do what they do and need little significant change to keep on doing it.
As far as I can see, ROBODoc requires that you do pretty much all the annotation work yourself, whereas NaturalDocs will derive a bit more for you. Not very much though; in particular, you will have to write plenty of annotations on things whichever route you use. (I've no particular experience with either though; I tend to prefer to maintain documentation in a separate file with something like doctools but that's a very different approach. I've also done nasty custom things in the past; you really don't want to use them.)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
The question says it all really.
What are the differences between these two methods that appear to carry out exactly the same function?
Is there guidance to say which should be used or are there conditions when you may use either?
The FileSystem.MoveFile has some more options than File.Move, like for example optionally showing a progress dialog, and creating the destination folder if it doesn't exist.
If you just want to move or rename a file, the File.Move method will be called in the end whichever you use, so calling it directly means slightly less overhead.
I believe they have near-identical functionality. Most people I've seen would prefer to use the latter, because "MyComputer." is a VB.NET-only construct, whereas File.Move is used in both C# and VB.NET. This makes it easier to get help, and easier for C# coders to read the VB.NET code and vice-versa.
I haven't checked My.Computer.FileSystem.MoveFile, but you can state if they are differences moving html files with associated images directories., because File.Move just move the file, but doesn't move the associated directory