Tutorial 21a

[magomimmo]

Here it is. I downgraded cljs to 1835, because there are some issues with domina/enfocus codebase when interacting with the piggieback base brepl. This way it works and you can use it for repling with enfocus too.

[ckirkendall]

@magomimmo I think we may have bitten off a bit more than we can chew in a short period of time. This stuff is great and I am excited but I may have to move it to another branch. I meant to create a 2.1.0-SNAPSHOT for this instead of 2.0.1-SNAPSHOT. I need the 2.0.1-SNAPSHOT for bug fixes and it has to have a working test suite. I will try to get everything in order over the course of this week. I did push out 2.0.0 release but have not publicized it yet.

[magomimmo]

@ckirkendall no problem. Just take into account the semantic versioning style guide. The refactoring of the enfocus project did not touch a single line of its codebase. So, from a third party point of view the usage of the lib is exactly the same. But you can eventually consider it as the base for the 2.1.0-SNAPSHOT release if something is going to be added to the lib itself without breaking the current 2.0.X-SNAPSHOT code.

Anyway, I'll also try to introduce austin, which seems to make our life easier while using the repl to develop clj/cljs application…..I'm curious about the creation of unit test which use the fixtures……

On Oct 16, 2013, at 2:47 AM, Creighton Kirkendall notifications@github.com wrote:

@magomimmo I think we may have bitten off a bit more than we can chew in a short period of time. This stuff is great and I am excited but I may have to move it to another branch. I meant to create a 2.1.0-SNAPSHOT for this instead of 2.0.1-SNAPSHOT. I need the 2.0.1-SNAPSHOT for bug fixes and it has to have a working test suite. I will try to get everything in order over the course of this week. I did push out 2.0.0 release but have not publicized it yet.

— Reply to this email directly or view it on GitHub.

[ckirkendall]

@magomimmo I am not really worried about the versioning. My biggest issue right now is because I don't have the test suite in the current branch its impossible to bug fix the 2.0.0 release. Good point on the version, I think I will make this a feature branch instead of a version so we can push it in when we get it to usable state. I did plan on bundling this with the view binding stuff that I planned to role out in 2.1.0 but those plans could change.

CK

On Wed, Oct 16, 2013 at 3:27 AM, Mimmo Cosenza notifications@github.comwrote:

@ckirkendall no problem. Just take into account the semantic versioning style guide. The refactoring of the enfocus project did not touch a single line of its codebase. So, from a third party point of view the usage of the lib is exactly the same. But you can eventually consider it as the base for the 2.1.0-SNAPSHOT release if something is going to be added to the lib itself without breaking the current 2.0.X-SNAPSHOT code.

Anyway, I'll also try to introduce austin, which seems to make our life easier while using the repl to develop clj/cljs application…..I'm curious about the creation of unit test which use the fixtures……

On Oct 16, 2013, at 2:47 AM, Creighton Kirkendall < notifications@github.com> wrote:

@magomimmo I think we may have bitten off a bit more than we can chew in a short period of time. This stuff is great and I am excited but I may have to move it to another branch. I meant to create a 2.1.0-SNAPSHOT for this instead of 2.0.1-SNAPSHOT. I need the 2.0.1-SNAPSHOT for bug fixes and it has to have a working test suite. I will try to get everything in order over the course of this week. I did push out 2.0.0 release but have not publicized it yet.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/ckirkendall/enfocus/pull/69#issuecomment-26397764 .

[magomimmo]

On Oct 16, 2013, at 2:30 PM, Creighton Kirkendall wrote:

My biggest issue right now is because I don't have the test suite in the current branch its impossible to bug fix the 2.0.0 release.

Sure, this is the real problem. In the week-end I'll start to use Enfocus in the context of the modern-cljs series of tutorials. In doing that I'll keep an open eye to understand what are the meaningful unit tests to be implemented (just to start) and eventually try to implement one of two of them.

Good point on the version, I think I will make this a feature branch instead of a version so we can push it in when we get it to usable state.

Yes, It can work in this way.

I did plan on bundling this with the view binding stuff that I planned to role out in 2.1.0 but those plans could change.

sure

mimmo

[ckirkendall]

@magomimmo I am almost at a point where I will begin integrating these changes in. If possible I would love you to take a look at the current state of 2.0.1-SNAPSHOT branch. I have all the core transform tests completed. I will integrate these changes in once I get the event tests completed.

[amacdougall]

Definitely curious to find out what happens with this -- right now I'm using lein-cljsbuild and Austin without specifying a hard ClojureScript dependency, and everything just works, but when I specified a cljs dependency in my project, everything went south in a hurry. One of the errors was piggieback-related, which seems to be what @magomimmo was seeing.

For now, I'll just avoid specifying a dependency until I have no choice! Let me know if I can help test anything related to this. In the meantime, I'll just keep hacking on my own project, since my Enfocus usage is pretty simple so far. There's more than enough to do over there.

[magomimmo]

@ckirkendall I'll take a look before tomorrow night. @amacdougall even if you do not specify a CLJS release, you're implicitly choosing one, the default one associated with your current cljsbuild release. @amacdougall I still have to investigate that problem, but it seems to me that should depends on different way to access properties in latest CLJS releases.

[magomimmo]

@ckirkendall I just noted two things:

1. you added the "test/clj" dir to the :source-paths con cljs sources. This breaks the separation of concerns principle. So, there should be a very serious reason to do it. Which is this reason?
2. I you take a look at the latest pull request, I added the :dev profile to the project.clj in such a way to keep development stuff separated from deployment stuff. So, another kind of application of separation of concerns principle.

Next few days I'll find the time to verify if is still possible to make the enfocus code to better respects those two points.

My best

[ckirkendall]

@magomimmo completely agree on the test/clj. I did that real quick to keep from breaking a thought when I was working on the macros for clojurescript.test integration. Forgot to go back and correct it when I finished up with what I was doing. I worked with :dev profiles before and it should help clean up several things.

[ckirkendall]

@magomimmo I was able to merge all of these changes in with my setup and got everything working.

[magomimmo]

@ckirkendall I have this result:

lein cljsbuild test whitespace
Compiling ClojureScript.
Running ClojureScript test: whitespace
Testing enfocus.core-test

FAIL in (sample-test) (:)

this test should fail

expected: (= 1 2)

  actual: (not (= 1 2))

Ran 26 tests containing 50 assertions.

1 failures, 0 errors.

TypeError: 'null' is not an object (evaluating 'parentElm.appendChild')

  file:///Users/mimmo/tmp/enfocus/dev-resources/public/js/whitespace.js:29247
  file:///Users/mimmo/tmp/enfocus/dev-resources/public/js/whitespace.js:357
opened: dev-resources/public/test_ws.html
2

{:test 26, :pass 49, :fail 1, :error 0, :type :summary}

I'm trying to understand the way you the design the unit testing. Could you elaborate a little bit about it?

Thanks thousands

[ckirkendall]

That is the expected results except for the TypeError. I will have to look at that because I don't have that issue. If you open up in a browser dev-resources/public/test_ws.html you will see the browser output of the test. If you take a look at the console you will see the same results you get from running lein cljsbuild test.

The basic design hinges on overriding report multimethod in clojurescript.test. This is sort of the standard way to do this with clojure.test so I felt it was good way to go for clojurescript.test. The defmethods have to be overridden per namespace so I decided to create macros for the defmethod. If you look test_setup.clj under /test/clj/enfocus you will see the code. These add the results of each test to an atom in the report_generator.cljs namespace. This atom is then processed to create the UI representation of the tests.

The runner.js was modified to load an html file and all calls relating to clojurescript.test were removed. Calls to run-all-tests and to generate reports were moved into a script block inside each of the html files. This way they will load in the browser and in phantom with no modifications.

I have attached a screen shot of what it looks like in the browser.

[ckirkendall]

I was able to reproduce the the type error. It is related to the browser repl. I think it has to do with browser trying to connect before the body tag has rendered. Might need to put the connect on load or maybe move the script tags below the body tags.

[ckirkendall]

@magomimmo I pushed a fix to the type error.

[magomimmo]

WOW, this is a big result. Congratulations. I have few questions: a) Why are we using ring stuff? I ported that stuff in the new directories layout and project.clj because I was thinking that you need it during the testing. Is that wrong? If it's wrong we should remove all that ring stuff from there. b) I'll try to figure out how to eliminate the test/clj dir path from the :source-paths in the cljs builds. It seems it is there just because of the defmacro, right?

Great work! My best

[magomimmo]

Hi Creighton, I'm thinking loud now, so I could say things to be elaborated if not stupid:

If I understood your path, you modified the phantomjs.js script to be able to pass it an HTML page instead of a JS Script. And why you needed to pass an HTML instead of a JS Script? Again, if I understood right, you want a js/document used in the each-fixture to prepare the DOM for being manipulated by enfocus. Then you execute the unit tests to verify the DOM manipulation current result with the expected result, and finally you clear the DOM for the next unit test to be executed. Is this interpretation right? My question is: could we use the deftemplate macro to create the initial DOM from an HTML page in the dev-resources/public directory? I kept the ring stuff in the :dev profile of the project.clj file because I was thinking that you needed an http-server to create a DOM by calling deftemplate on a URL. This way we could completely eliminate the need to override the cemerick.cljs.test/report method and even the need to modify the runner/phantomjs.js script and stay with the standard clojurescript.test mechanics (if I'm not wrong).

My approach would have been something like the following:

1. create the fixture by using deftemplate which read an HTML page from the dev-resources/public dir path.
2. execute the unit tests using the :each fixture feature
3. leave the reporting facilities as they are

Also I do not understand why we need to create an HTML result page for the testing if we already have the same result from the lein test command.

Where am I wrong?

My best

Mimmo

[ckirkendall]

Not sure I fully followed what you are saying. We need to have the results viewable in the browser so we can setup multiple browser testing. Lein test only tests inside phantom. Phantom testing is great but for a dom manipulation tool that has to support lots of browser setups it is only a partial guarantee that things will work in older browsers or even in some modern mobile ones. The html files give us a way to run the test in any browser and view the results. That is the only reason to create the html files. A good example of these types of issues happened when creating the unit tests. One of the tests passed just fine in phantom when but failed in firefox. The issue was that firefox including some additional default settings when checking the background style attribute that phantom and chrome does not.

Ring is needed mainly to support testing of remote templates. I don't generally use it, as I start chrome with the ability to load local files when testing things, but most people won't do that so I have to have a server to that makes it possible to load the remote templates without throwing a cross site scripting error.

Can't use deftemplate as I am trying not to use any enfocus items in the structure of testing so bugs in enfocus wont cause issues with the testing display. I also plan on externalizing the setup at a later date.

Hope these explanations help.

[magomimmo]

On Oct 22, 2013, at 5:03 PM, Creighton Kirkendall notifications@github.com wrote:

The html files give us a way to run the test in any browser and view the results. That is the only reason to create the html files. A good example of these types of issues happened when creating the unit tests. One of the tests passed just fine in phantom when but failed in firefox. The issue was that firefox including some additional default settings when checking the background style attribute that phantom and chrome does not.

Have you seen this? https://github.com/cemerick/clojurescript.test/issues/10

It should allow to repeat the test on gecko too. But I really don't know if there is something similar for MS IE.

Ring is needed mainly to support testing of remote templates.

Ok, this is what I was thinking it's used for. I don't generally use it, as I start chrome with the ability to load local files when testing things, but most people won't do that so I have to have a server to that makes it possible to load the remote templates without throwing a cross site scripting error.

perfect! It matches with my intention to bring ring in the 2.0.1-SNAPSHOT.

Can't use deftemplate as I am trying not to use any enfocus items in the structure of testing so bugs in enfocus wont cause issues with the testing display.

that makes sense, but if I understand right the actual html page you're using for testing has only the body (aside from the script), then you manipulate it while executing the unit tests. So, if the deftemplate has no bugs for such a tiny thing I think it's usable for creating the fixture.

As a returned value, you have a very standard clojurescript test (and you do not need to add any CLJ source (i.e. test/clj dir) into the cljsbuild source-paths

I also plan on externalizing the setup at a later date.

What you mean by externalizing the setup? Hope these explanations help.

sure…

thanks so much

— Reply to this email directly or view it on GitHub.

[ckirkendall]

I did see the gecko support but that doesn't address things like IE, different browser versions or mobile. I already removed test/clj from the source paths. It is listed only in the dev profile for the creation of the different testing js files. I am sorry if I forgot to mention that.

I am very confused on why you want to use deftemplate. The code for the fixture is very small and doesn't have any dependencies on enfocus. It also has no dependencies on the macros for reporting. Below is the code for the fixture, it is in report_generator.cljs. If you notice it only creates a 'div' with a child 'p'. I purposely do not want any dependencies with enfocus or domina because the whole setup for multi-browser testing with clojurescript.test can and will be externalized into a library and used in domina and others.

(defn each-fixture [func]
  (let [div (.createElement js/document "div")
        pc (.createElement js/document "p")]
    (.setAttribute div "id" "test-div") 
    (.appendChild (.-body js/document) div)
    (.appendChild div pc)
    (func)
    (.removeChild (.-body js/document) div)))

Hope that makes things a bit more clear.

CK

[magomimmo]

Hi Creighton, don't worry to much about this, As I said I was thinking aloud. I would prefer not to have the test/clj in the :source-paths of the cljsbuilds (because of my obsession with the separation of concerns principle) and not to have to modify the phantomjsscript (because of my obsession with the DRY principle). But I understand your point. By just passing an html page to the phantomjs script and modifying the reporting method you're able to test any browser (mobile included). That's a very good point.

Next days I'll eventually ti think a little bit more about my obsessions to see if it's possible to stay solid with the separation of concerns and DRY principles without get crazy with the clojurescript.test. As you know Chas asked: Wanted: runners for other JavaScript environments, e.g. Rhino, XUL, node, etc.

So it seems that clojurescript,test could cover more JS engines in the near future which will eventually solve our multi-browsers testing need for enfocus. But in the mean time your approach seems to be the easier to be follow.

thanks so much all your explanations.

Mimmo

[ckirkendall]

@magomimmo I am a little confused on the separation of concerns, because the only purpose of the cljsbuilds is for testing. So having test/clj in the source path seems like the proper place it would exist. I agree on the DRY principle. It is very possible to pull out what is in the html files into a small piece of clojurescript code that is bundled in and registered on load. I might look into to doing that but right now I want to get more of the base test cases completed. In particular the events and template test cases. I am still thinking about how best to approach the async stuff.

[magomimmo]

Separation of concerns is a kind of orthogonal concept. We were able to keep separated the cljs code from the clj code in the sources of enfocus. We were even able to keep separated the resources used for testing from the rest of the sources. If we are able to keep separated even the clj sources from the cljs source used for testing purpose that would be a complete application of the separation of concerns principle. But, as I said, I'm too much fanatic about that principle.....