Context
I have a function that operates on a data structure.
I have written a spec for the data structure this function operates on.
This function returns a reagent component that is rendered in a browser (PhantomJS)
The spec has some optional keys, and depending on whether or not those keys exist in the data when it's passed to the function, the output (component to be rendered in browser) of the aforementioned function will be affected.
I am looking to use clojure.test to compare values of the data structure passed to the function generating the component with values grabbed from the rendered element, so simple unit test or input->output comparison is not what I'm going for here.
Problem
Since calling generate or sample on the spec generator will sometimes include or omit the optional fields, I would like to iterate over a reasonably large set of data generated using sample and test each of the data structures, but I don't know the "right" or idiomatic way to do this.
I have used are in clojure.test before, which is great, but since I'm testing against the rendered component in the browser, and are tests input->output it doesn't seem like the right tool for the job.
Advice on a generally accepted practice here or language/clojure.test feature that would have me doing this in the most idiomatic way would be greatly appreciated.
compare values of the data structure passed to the function generating the component with values grabbed from the rendered element
If possible, I'd use s/fdef with :args, :ret, and :fn args to specify the relationship between your function's input and output, and then check the function. There's an example in the testing section of spec guide.
iterate over a reasonably large set of data generated using sample and test each of the data structures
This is essentially what check does.
As for clojure.test integration, you can check functions as part of a test suite like this:
(deftest foo-test
(is (not (:check-failed (st/summarize-results (st/check `foo))))))
Related
There's a pattern I haven't figured out for Component yet:
I have some "live" configuration that requires disk IO (a component) on system-start, and has a dependency on a map of static config (.edn), and after this "live" configuration is instantiated, it won't change or side-effect anything anymore.
For ex: I need to set this up once, and it depends on static config:
(buddy.core.backends/jws
{:secret (buddy.core.keys/public-key
path-to-public-key-from-static-config)})
I would then reuse that backend ad-infinitum, (ex: in buddy.auth.middleware/wrap-authentication), and it doesn't change, nor side-effect.
Possible Solutions
I could make a component that stores this backend at system-start. But this gives up generality, because when I want to add similar "live config", it would have to be explicitly written into the component, and that gives up the spirit of generality that I think Component champions (eg Duct says components define side-effects, and create boundaries to access them)
I could pass a generic component a map of keys - [fn & args] and the fn+args get evaluated and stored in the component. But this feels like it offloads computation to my configuration .edn, and is an anti-pattern. For example:
(private-key priv-path-from-static
(slurp :password-path-from-static))
Should I encode the notion of slurping in my .edn config? I don't want to offload computation to a config file...
The backend and keys can be instantiated on a per-need basis within each component that requires them. IMO, that's too much of computing the exact same thing, when I'd rather it be stored in memory once.
I could have an atom component that holds a map of these "live" config objects, but then they get destructively added in, and my code has lost it's declarative nature.
TL;DR
What's the best way to create configuration at system-start, possibly needing dependencies, and then becoming available to other components as a component, while not giving up the generality which components should have?
In an ideal world, I think the component itself should describe what type of configuration data it needs. (This could be done with a protocol extending the component in question.). When the config component is started, it should look at all other components, get the list of config requirements and resolve it somehow (from a file, a database, etc.).
I've not seen such a library, but Aviso's config library comes close, maybe you can adapt it to your needs.
I have a very complex form. I need to get the post parameters from that form in the order they have been submitted. The application is created in ring/compojure.
All the parameters that I can get from ring request are preprocessed (grouped, sorted..)
How do I get the raw parameter list (preferably parsed to key/value vector or some other list)?
Could you provide more information about your project. What HTTP server are you using (http-kit, clj-http, aleph), and what middleware do you have applied in your project?
All parameter based things aren't actually part of the ring spec, but are handled by middleware (see https://github.com/ring-clojure/ring/wiki/Parameters), so it greatly depends on what bits you're currently pulling in.
I'm not aware of any ring middleware that currently exist that do you want, they all seem to parse the parameter list and put it into a hashmap, and if multiple parameters exist with the same key name, they make the value in the hashmap a vector of the items.
That all being said, I have to ask. Why do you need them in a particular order?
Your best option is to create your own middleware. Use the wrap-param middleware as a guide. You just need to do your custom stuff at https://github.com/mmcgrana/ring/blob/master/ring-core/src/ring/middleware/params.clj#L29
That said, I also be wary of expecting the params in a particular order as it will make brittle the client-server communication.
This may actually be a bit of an XY-problem, so I'll try to explain what the goal is first.
I'm building a ClojureScript application which is composed of a set of Reagent components. It provides a user interface where you can dynamically add or remove UI elements. These UI elements (components) have a certain type. For example a Markdown component is-a Text component. Whenever the user is presented with the option to add Text we list all the components that match the type+descendants (in this case Markdown, there could be others).
The way I've coded it up is as follows.
Each component is in its own namespace, this namespace contains a builder function that returns the new component. At the root of the namespace it also calls (derive ::type ::parent)
now in some different namespace we require and enumerate all of these components in a map like:
(ns app.components
(:require
[app.gui.markdown :as markdown]
[app.gui.study-list :as study-list]))
(def all
{markdown/t markdown/builder
study-list/t study-list/builder})
Where the /t refers to the namespace-qualified keyword which was used to define the hierarchy. We use the all map to provide the data for the menu's that face the user (which components can be added, filtered by type).
Now, as you can imagine, this isn't pretty. Since it must now maintain such a (potentially) long list of all the types in the hierarchy manually.
Rather I would do something like (def all (components-of (descendants ::root))) but I'm unsure how to tackle this, since I think it would require finding vars by name (not supported in ClojureScript).
So my question is: how do you maintain a map or list of namespaces + vars (dynamically) in ClojureScript?
You cannot do this dynamically, but as far as I can tell for your problem there isn't much need. ClojureScript macros can reflect back into the compiler - you could easily use the cljs.analyzer.api namespace to figure out which vars you need (through var metadata or whatever) and automatically emit the runtime info map you want. This is in fact very similar to how cljs.test/run-tests works. It uses the compiler to filter out all vars in all namespaces with :test metadata attached and it generates the code to test each one. It's worth examining cljs.test in detail to see how this can be done.
I have a controller method that fetches data to render(fetched data) a HTML view of the same. I wanted to write a test to ensure the jpa model is queried correctly. However I am not finding a way to intercept what is being passed into render().
Can someone please let me know if there is a way to get what is passed into render from a test case. If not should I move this code/line into a different class that I can test easily.
Thanks
I know it's not exactly what you want but you could just write some selenium tests that will confirm whether the controller is rendering the correct data in the template. (see: http://www.playframework.org/documentation/1.2.4/guide10#selenium)
Also writing a Functional Test may help (see: http://www.playframework.org/documentation/1.2.4/guide10#controller)
Could you see if the Play Response object i.e. the out contains your expected value?
This is an interesting question I am sure a lot of people will benefit from knowing.
a typical web service will return a serialized complex data type for example:
<orgUnits>
<orgUnit>
<name>friendly name</orgUnit>
</orgUnit>
<orgUnit>
<name>friendly name</orgUnit>
</orgUnit>
</orgUnits>
The VS2008 unit testing seems to want to assert for an exact match of the return object, that is if the object (target and actual) are identical in terms of structure and content.
What I would like to do instead is assert only if the structure is fine, and no errors exist.
To perhaps simplify the matter, in the web service method, if any error occurs I throw a SOAPException.
1.Is there a way to test just based on the return status
2. Best case scenario would be to compare the doc trees for structural integrity of target and actual, and assert based on the structure being sound, and not the content.
Thanks in advance :)
I think that this is a duplicate of WSDL Testing
In that answer I suggested SoapUI as a good tool to use
An answer specific to your requirement would be to compare the serialized versions(to XML) of the object instead of the objects themselves.
Approach in your test case
Lets say you are expecting a return like expected.xml from your webservice .
Invoke service and get an actual Obj. Serialize that to an actual.xml.
Compare actual.xml and expected.xml by using a library like xmldiff(compares structural /value changes at XML level).
Based on the output of xmldiff determine whether the webservice passed the test.