From this commit onwards, in order to run all of the tests, you
must now have postgresql installed and running on your dev
environment. The credentials/config is:
* Database name: elsa-yessql
* Username: postgres (this is the default anyway)
* Password: Password12! (this matches AppVeyor's postgres password)
* Port: 5432 (this is the default anyway)
This change means that a service provider may use both the Frozen
specimen builder and also the 'with autofixture resolution' behaviour.
That means that some unwanted extra logic in the test may now be
removed, with the test objects also coming from Autofixture.
This now also includes reworking the attribute which activates
Autofixture-style resolution upon an IServiceProvider.
This has now been renamed to WithAutofixtureResolutionAttribute.
The new/reworked attribute is composable with other Autofixture
attributes.
This isn't really related to #751 - it's a refactor of some of
our test logic, to avoid bloat of semi-repeated autofixture
customization attributes.
By switching to a behaviour-driven model, it's possible to
compose them, which means that there's no need to part-duplicate
between them. It should also reduce the overall number of them,
as combinations can be put together on-demand, rather than needing
a new attribute of their own.
This removes all of the (now actually non-trivial) conversion logic from
the class which is actually responsible for executing the Jint engine.
This moves it all to a new service which uses chain of responsibility to
convert the result, using one of a few different mechanisms.
Of note is the handling of ExpandoObject when no specific type
information has been provided, and also the handling of enumerables,
with the exception of strings.
Unfortunately Jint still chokes in this case if the expando contains
further nested expandos. It turns out that I need to do this
recursively for it to always work.
We also have trouble with IEnumerable types. They also can't be
round-tripped from/to JSON when they aren't deserialized as a very
specific type.
It appears that this can be fixed by intercepting occasions
when Jint returns an ExpandoObject but the desired return type
is simply object. In this scenario we must return
a Dictionary<string,object> instead of a simple object, or else
Jint freaks out should we try to stringify it later.
I also added a second test to prove that making this change hasn't
broken the way we expect Jint to work for us.
This replaces the `Then(string activityName)` method with `ThenNamed(string activityName)`.
A new method is added to allow connecting to activities by type name: `ThenTypeNamed(string activityTypeName)`.
The reason for this change and addition is to allow workflow builders to connect to activity types that do not have a corresponding type.
For example, the Telnyx project has an activity type provider that *dynamically* provides activity types based on Telnyx webhook callback types.
This means that the model:
* Implements IConvertible so that Jint may implicitly convert
it to other types as if it were just a string.
* The Values & Values properties are perhaps a little less confusing
now, and present a more consistent set of state, regardless of
the inner model.
* There's a minor simplification to ToString, since String.Join already
did what we wanted for one or many values.
Notable though is - because this class implements IConvertible,
it is no longer CLS compliant. We do not currently mark this assembly
as CLS complient so as things stand that's OK. I do not know if there
are any plans/expectations for CLS compliance in Elsa.
If we do plan to mark the assemblies as compliant then we must mark this
class [CLSCompliant(false)].
The issue here is that the elsa.db for sqlite is going in the same
path every time. Depending on the order in which tests are run,
sometimes it means that migrations are run on a DB which is
expected to be empty but which already exists. That causes an
error & test failure.
Here I've just used temp folders to ensure that the DB file is in a
different path every time.
One of these tests is failing and this is the one which
demonstrates issue #738. The composite activity which begins
with ReceiveSignal doesn't generate a trigger.
This extension method is quite complex and is frustrating
when a unit test passes-through it. That's because extension
methods can't be mocked in tests.
The triggers-for-activity-blueprint functionality
is quite complex just on its own, so I have moved this to
a new service.
Once again the integration test which is left behind proves
that it still does the same job.
As stated in the comments for
WorkflowMayContainDuplicateActivitiesIntegrationTests
These tests might not describe actually-desired behaviour.
If they begin to "get in the way" in future, then it would
probably be safe to remove them.
As well as providing a unit test which matches other persistence
provider tests (round-tripping a workflow instance), two other tests
are included here:
* When using the default DI registration extension method, this sets
up pooling of DB contexts and so a resolved context will come from
the pool.
* When using the non-pooled DI registration extension method, this
sets up EF without pooling, which is more useful in a multi-tenanted
environment.
There are also some other changes in this commit corresponding to
improving the tests. Mainly de-duplicating logic & improving names.
This also includes a change to the workflow used in the test-case.
There are quite complex reasons for this, as explained here:
https://github.com/elsa-workflows/elsa-core/issues/728#issuecomment-794319236
The real crux of it is that the workflow must have an activity
which suspends it, and that activity that suspends the workflow
must not be the starting activity. This is why I added an unused
set-variable activity as the starter.
This commit shows that the various persistence test cases _mostly_
work OK, with the one exception of ActivityExecuted.
