This question already has answers here:
Can I create shared test utilities?
(2 answers)
Closed 1 year ago.
I have the following architecture :
- package-a
- a.go
- a_test.go
- package-b
- b.go
- b_test.go
- package-c
- c.go
- c_test.go
I would like to use data initialized in a_test.go inside of b_test.go, is it possible ?
Example :
var FakeData = FakeData{ something... }
I have made my own researches and it look like it is not possible to share data across different package's tests files.
How to share test interfaces between Go packages?
https://github.com/golang/go/issues/10184
First : is my assumption correct ?
Second : do you know of any documentation that would enforce the fact ?
I have looked at https://golang.org/ref/spec but could not find anything.
Thanks
I would like to use data initialized in a_test.go inside of b_test.go, is it possible ?
No, this is not possible.
is my assumption [is not possible to share data across different package's tests files] correct ?
Yes.
do you know of any documentation that would enforce the fact ?
Yes. That is how testing works. Running go test will include the _test.go files from the package under test and produce a synthetic main package which can be compiled and linked to an executable which then is executed. No other _test.go files are included ever into that test binary. There is no documentation that explains this "No other!" fact, but this is implicit from the "only the test files from the current".
Provide a "real" package (probably an internal one) providing this test data from non- _test.go files.
Related
I've had trouble with this issue across many languages, most recently with C++.
The Issue Exemplified
Let's say we're working with C++ and have the following file structure for a project:
("Project" main folder with three [modules, data, etc] subfolders)
Now say:
Our maincode.cpp is in the Project folder
moduleA.cpp is in modules folder
data.txt is in data folder
moduleA.cpp wants to read data.txt
So the way I'd currently do it would be to assume maincode.cpp gets compiled & executed inside the Project folder, and so hardcode the path data/data.txt in moduleA.cpp to do the reading (say I used fstream fs("data/data.txt") to do so).
But what if the code was, for some reason, executed inside etc folder?
Is there a way around this?
The Questions
Is this a valid question? Or am I missing something with the wd (working directory) concept fundamentals?
Are there any methods for working around absolute paths so as to solve this issue in C++?
Are there any universal methods for doing the same with any language?
If there are no reasonable methods, how would you approach this issue?
Please leave a comment if I missed any important details with the problem's illustration!
At some point the program has to make an assumption where the file(s) are. Either by getting it from user input or a relative path with the presumed filename. As already said in the comments, C++ recently got std::filesystem added in C++17 which can help you making cross-platform code that interacts with the hosts' filesystem.
That being said, every program, big or small, has to make certain assumptions at some point, deleting or moving certain files is problematic for any program in case the program requires them to be at a certain location under a certain name. This is not solvable other than presenting the user with an error message etc.
As #Hatted Rooster said, it's not generally solvable for some arbitrary file without making some assumptions, however there are frameworks that allow you to "store" some files in the resources embedded into the executable (or otherwise). Those frameworks would usually allow your to handle such files in a opaque way, without the need to rely on a current working dir or relative paths.
For example, see the Qt Resource System.
Your program can deduce the path from argv[0] in the main call, if you know that it is always relative to your executable or you use an absolute path like "C:\myProgram\data\data.txt".
The second approach works in every language.
This issue describes the concept
https://github.com/dart-lang/source_gen/issues/272
To summarize:
I am using source_gen to generate some dart code.
I am using json_serializable on the generated dart code.
I wish to output all of the results to a source directory adjacent or below my target source.
The desired directory structure
src
feature_a
model.dart
gen
model.g.dart
model.g.g.dart
feature_b
...
I have considered building to cache however it seems json_serializable doesn't support this and even if it did I don't know if its even possible to run a builder on files in the cache.
I've also considered an aggregated builder that is mentioned here.
Generate one file for a list of parsed files using source_gen in dart
But json_serializable is still an issue and the source_gen version in that post is super old and doesn't describe the solution well.
This is not possible with build_runner. The issue to follow is https://github.com/dart-lang/build/issues/1689
Note that this doesn't help much with builders that you don't author, and wouldn't work with things like SharedPartBuilder.
I am new to unit testing and the Qt framework. I have been assigned to write a unit test to test the opening of text files.
I have looked the the tutorials for Qt test. But I have no idea how to proceed. (I have to use QTestLib). Please guide me what I should do.
Boost libraries are being used to open the csv and delimited text-files to import the data in the application.
By testing, I am assuming that you want to check if the files are being read properly.
1) To get a better understanding about the Qt Project structure, check out this link
2) Locate the class that is actually calling the boost libraries to read the data, you might want to test this class (It depends on you how you want to implement, without any details, I cannot give a better explanation)
3) Create the corresponding object and invoke the reading of the file. After the file has been read, you can QVERIFY or QCOMPARE the data read by the class and the actual values. To use custom datatypes in the previous functions, look at this link. It is explained in the website, how to create and use custom datatypes for the above functions.
4) To run multiple tests in a single Test project (Qt), look at this github repo (I'm unable to find the website where it was originally posted).
I hope this gives an idea of how to get started with writing the test. It really depends on what your requirements are, without knowing the details, I might not be able to help more
My Dart package is currently laid out in the following manner:
lib/
mypackage.dart
src/
mypackage_util.dart
test/
mypackage_test.dart
Inside mypackage.dart, I'm using the part, part of import strategy to use
mypackage_util.dart in mypackage.dart, as recommended by the Pub Layout
conventions.
On the test side, I took inspiration from Seth Ladd's example of using
unittest,
which shows him creating a new library for his tests, which makes sense to me.
Unfortunately, this leads to the inability to import mypackage_util.dart into
mypackage_test.dart, which means I can't test classes or functions from
mypackage_util.dart, or anything in src/.
The solutions I'm imagining are;
Make mypackage_test.dart a part of the main library, but this seems to make
it impossible to just run the test code stand-alone.
Take mypackage_util.dart out of src/, but this seems to imply that you
can never unit test src/ code in packages, which seems silly and exposes
code I don't want to.
Should I take one of the above approaches, or am I missing something?
Update:
The above situation was due to a library import conflict (see Chapter 2. Dart Tour's Libraries and Visibility section for solutions to library conflicts). See comments below.
If lib/mypackage.dart declares the library and includes lib/src/mypackage_util.dart using part/part of you just need to include lib/mypackage.dart in your test - or is your problem that you want to test private classes/functions contained in lib/src/mypackage_util.dart?
I'm working on a C++ library that (among other stuff) has functions to read config files; and I want to add tests for this. So far, this has lead me to create lots of valid and invalid config files, each with only a few lines that test one specific functionality. But it has now got very unwieldy, as there are so many files, and also lots of small C++ test apps. Somehow this seems wrong to me :-) so do you have hints how to organise all these tests, the test apps, and the test data?
Note: the library's public API itself is not easily testable (it requires a config file as parameter). The juicy, bug-prone methods for actually reading and interpreting config values are private, so I don't see a way to test them directly?
So: would you stick with testing against real files; and if so, how would you organise all these files and apps so that they are still maintainable?
Perhaps the library could accept some kind of stream input, so you could pass in a string-like object and avoid all the input files? Or depending on the type of configuration, you could provide "get/setAttribute()" functions to directly, publicy, fiddle the parameters. If that is not really a design goal, then never mind. Data-driven unit tests are frowned upon in some places, but it is definitely better than nothing! I would probably lay out the code like this:
project/
src/
tests/
test1/
input/
test2
input/
In each testN directory you would have a cpp file associated to the config files in the input directory.
Then, assuming you are using an xUnit-style test library (cppunit, googletest, unittest++, or whatever) you can add various testXXX() functions to a single class to test out associated groups of functionality. That way you could cut out part of the lots-of-little-programs problem by grouping at least some tests together.
The only problem with this is if the library expects the config file to be called something specific, or to be in a specific place. That shouldn't be the case, but if it is would have to be worked around by copying your test file to the expected location.
And don't worry about lots of tests cluttering your project up, if they are tucked away in a tests directory then they won't bother anyone.
Part 1.
As Richard suggested, I'd take a look at the CPPUnit test framework. That will drive the location of your test framework to a certain extent.
Your tests could be in a parallel directory located at a high-level, as per Richard's example, or in test subdirectories or test directories parallel with the area you want to test.
Either way, please be consistent in the directory structure across the project! Especially in the case of tests being contained in a single high-level directory.
There's nothing worse than having to maintain a mental mapping of source code in a location such as:
/project/src/component_a/piece_2/this_bit
and having the test(s) located somewhere such as:
/project/test/the_first_components/connection_tests/test_a
And I've worked on projects where someone did that!
What a waste of wetware cycles! 8-O Talk about violating the Alexander's concept of Quality Without a Name.
Much better is having your tests consistently located w.r.t. location of the source code under test:
/project/test/component_a/piece_2/this_bit/test_a
Part 2
As for the API config files, make local copies of a reference config in each local test area as a part of the test env. setup that is run before executing a test. Don't sprinkle copies of config's (or data) all through your test tree.
HTH.
cheers,
Rob
BTW Really glad to see you asking this now when setting things up!
In some tests I have done, I have actually used the test code to write the configuration files and then delete them after the test had made use of the file. It pads out the code somewhat and I have no idea if it is good practice, but it worked. If you happen to be using boost, then its filesystem module is useful for creating directories, navigating directories, and removing the files.
I agree with what #Richard Quirk said, but also you might want to make your test suite class a friend of the class you're testing and test its private functions.
For things like this I always have a small utility class that will load a config into a memory buffer and from there it gets fed into the actually config class. This means the real source doesn't matter - it could be a file or a db. For the unit-test it is hard coded one in a std::string that is then passed to the class for testing. You can simulate currup!pte3d data easily for testing failure paths.
I use UnitTest++. I have the tests as part of the src tree. So:
solution/project1/src <-- source code
solution/project1/src/tests <-- unit test code
solution/project2/src <-- source code
solution/project2/src/tests <-- unit test code
Assuming that you have control over the design of the library, I would expect that you'd be able to refactor such that you separate the concerns of actual file reading from interpreting it as a configuration file:
class FileReader reads the file and produces a input stream,
class ConfigFileInterpreter validates/interprets etc. the contents of the input stream
Now to test FileReader you'd need a very small number of actual files (empty, binary, plain text etc.), and for ConfigFileInterpreter you would use a stub of the FileReader class that returns an input stream to read from. Now you can prepare all your various config situations as strings and you would not have to read so many files.
You will not find a unit testing framework worse than CppUnit. Seriously, anybody who recommends CppUnit has not really taken a look at any of the competing frameworks.
So yes, go for a unit testing franework, but do not use CppUnit.