I have a Testcafe project, that needs to run in multiple environments, with different options located in .testcaferc, so something that would allow me to have multiple configuration files is needed.
Currently I don't see how this could be implemented.
What would be the best approach to solve this.
Related
My searches have turned up nothing concrete. My extension uses Google's file picker to allow the user to browse their sheets and choose a desired file to write some data to, which manifest v3 breaks because of some GAPI limitations. Unless I've missed something obvious, there does not seem to be a simple workaround or method for this to migrate to v3 -- it just seems to be disallowed.
I'm not asking if there's a way to do something that they intend to not be possible (even though I doubt such a thing would exist with Google) but I'm optimistically hoping that maybe there is some hacky/annoying workaround that still fits within their rules. If I absolutely have to just allow them to set a sheet URL manually I will...I'm just trying to avoid it.
Any tips or suggestions would be appreciated.
You may have to test it yourself to make sure there are no weird behaviors, but Google has some recommendations regarding this in their migration guide:
In Manifest V3, all of your extension's logic must be included in the extension. You can no longer load and execute a remotely hosted file. A number of alternative approaches are available, depending on your use case and the reason for remote hosting. Here are approaches to consider:
Configuration-driven features and logic
In this approach, your extension loads a remote configuration (for example a JSON file) at runtime and caches the configuration locally. The extension then uses this cached configuration to decide which features to enable.
Externalize logic with a remote service
Consider migrating application logic from the extension to a remote web service that your extension can call. (Essentially a form of message passing.) This provides you the ability to keep code private and change the code on demand while avoiding the extra overhead of resubmitting to the Chrome Web Store.
Bundle third-party libraries
If you are using a popular framework like React or Bootstrap, you can download the minified files, add them to your project and import them locally.
For your case, option #3 seems like the easiest. Looking at the Google Picker API documentation it only uses two relatively small script files, https://apis.google.com/js/api.js and https://accounts.google.com/gsi/client. You could try to bundle these in your Chrome extension and call the methods locally.
I have an IdS (Thinktecture Identity Server3) and various web sites trusting the IdS.
I have selenium tests for IdS and for each of the sites.
I use TeamCity and Octopus Deploy.
Changes in IdS should trigger test of dependent web sites. Changes in individual sites should trigger only test of the site (as it is).
What is the best way of ensuring this? I should think this is a common problem? ;)
BR, Anders
One way to do so, is to use App settings configuration options of the .Net itself. You can use config transformations to create different configuration per site and change. You will have to however map each, though. This will allow you to keep everything in the project. Example of such script creating transformed config files using the command line transform execution tool. Or if you prefer to use TeamCity with XML pokes. I've used the later with great success on Selenium and multi site platform test framework. Before each test build that was chained, we modified the XMLs, so the execution was dedicated to the related Git branch or repo that TeamCity was set to monitor.
I found what I was looking for in the most obvious of places. On the web site builds, I added a Finish Build Trigger pointing to the ids build. This way all my sites (I have only one :)) gets selenium tested.
There should be a way where user should be able to access test cases and select or customize them online before running. Or in simple terms is it easy to use feature files online.
I think what you want is Jenkins
After you set up your Jenkins server you can access it though a web page, create jobs, and run them. There are also reporting plug-ins like Cucumber Reports that make nice, easy to read, reports.
I'm using FuseESB to run my app, which is essensially OSGI container (Felix), i'd like to figure approach to test my OSGI services in integration mode (including outer dependencies like DB, outer services, etc). First on a thought is ability to run specific bundle into container which involve all app services into running tests defined in this bundle. Can somebody help with that kind of issue? THANKS!
There are differnt ways of testing this.
Since FuseESB is based on Apache Karaf you might test with the apache karaf-pax-exam tools to test a complete container setup automatically.
Another way of just testing your OSGi bundles in a OSGi container is to use pax-exam directly. Last but not least if you just want to test your service look-up functionality you might test with pojosr, it's quite nice for testing but has it's limits especially if you depend on container features.
That said you'll find information at the following pages:
Pax-Exam
Apache Karaf
sample how Pax-Web uses pax-exam in its iTests
You may find http://www.javabeat.net/2011/11/how-to-test-osgi-applications/ helpful as an overview of the various OSGi test options. Configuring PAX-Exam to pull in your whole FuseESB container and get all your app services present will involve certain challenges, but once you've got the knack it can be very handy.
bndtools as the possibility to do JUnit tests inside the container.
I am working on a large project that comprises a server, some plugins for controlling devices that can be loaded into the server process, and also clients that can connect to the server. I am looking for the best practice for structuring the framework(s) that will ultimately need to exist.
There are header files that are shared between client, server, and plugins, and some headers that are specific to each aspect of the system. Sometimes headers are only shared between say client and server, or server and plugin. Similarly, there is common code that can be shared between all three aspects of the project, and also code that would only be needed by one particular aspect.
When the project is finished, we will need to release a client application and plugin developer API for third parties to develop against.
I am not sure how to properly structure the Frameworks that would be needed to support this.
Do I need to have 2 separate frameworks? Or can I have 1 framework that includes all the headers and provides 2 separate dylibs?
If I need to have 2 separate frameworks, what do I do with header files that are shared between all aspects of the system? I do not want to copy them into each framework to avoid possible problems with versioning.
Would a 3rd headers-only Framework be a reasonable option?
Can anyone recommend a best practice for structuring this kind of thing with Frameworks on OS X?
Framework = library + headers for that library
Each framework only needs to include header files for the interfaces you want to expose. Even if common headers were used to build all three frameworks, you are not obliged to bundle them.
A 3 framework approach would be fine, even if one of the frameworks only bundles common headers and no library at all. Example: if you install Qt on your Mac, you will see it split across many frameworks, but headers are never duplicated among them. There are also some frameworks that only contain headers and no code (QtScript.framework, for instance).