Automated browser tests docs and execution about nitrogen HOT 4 CLOSED

Hey David!

I'm aware of Selenium and the Selenium Web Driver for erlang. That said, because the erlang driver has a modification to its licence that disqualifies it from being a true open source license, I decided to implement my own testing system in Nitrogen. This ensures that 1) it adhere's the Nitrogen's open source MIT license, and 2) because it relies exclusively on native nitrogen functionality, no addons are required.

As for the wf_test.hrl file not being mentioned in the docs: wf_test.hrl already is included in wf.hrl, hence why the the documentation for the testing system doesn't mention it.

The error message you mentioned is interesting,

For a few examples here that will help point you in the right direction, all of Nitrogen's actual tests can be found in the NitrogenProject.com repo.

Here are a few simpler examples:

• A pretty simple set of tests for a basic self-contained page: https://github.com/nitrogen/NitrogenProject.com/blob/master/src/tests/tests_dropdown.erl
• Adding tests to a page that already exists without adding the code to that specific page: https://github.com/nitrogen/NitrogenProject.com/blob/master/src/tests/tests_advancedcontrols1.erl (this adds tests to https://github.com/nitrogen/NitrogenProject.com/blob/master/src/demos/demos_advancedcontrols1.erl through the use of 'wf_test:start_other(OtherModuleName, TestStartFun)`
• A somewhat more complicated test that integrates a bunch of javascript into the tests: https://github.com/nitrogen/NitrogenProject.com/blob/master/src/tests/tests_cookie.erl

Basically, Nitrogen's testing system is its own self-contained system that does not use eunit or ct, and launched by:

1. Adding some new rules to the app.config, then
2. Launching it from the erlang shell with wf_test:start_all(nitrogen_core) (you can see it launched from the NitrogenProject repo here: https://github.com/nitrogen/NitrogenProject.com/blob/rebar3/Makefile#L106-L107)

Hopefully that helps!

from nitrogen.

Thank you. That is a great help. I will give this a go in a few hours and let you know if I manage to get it working running.

I don't quite under this syntax "##textbox > something > something_else ", I just assume that's is selector syntax similar to xpath which in slightly more familiar with.

The selenium driver has a few hiccups such as the inability to manage cookies amongst a few other things.

Though all in all this is great stuff.

from nitrogen.

Having tried this it is logical for the most part and everything pretty much runs as intended. I'm happy that I'm able to at least to launch the browser. The issue is that its more directed at elements. This is find as it would be useful when I start developing the bulma plugin when I get some time.

The issue with what I have now is simply that loading the test is not completely possible. Even when using the start other feature. For example is I reference in app.config tests/web_test.erl, it will literarily load that path. Though the page I maybe trying to test will be located at lets say /login.

From a plugin and element development side of things it makes sense. But the fully built application maybe a little bit more difficult. I would of liked to see the element get filled in by the value after the browser is launched.

All in all for now I'm going to have to focus solely on Eunit tests until I'm developing framework add-ons.

I will also try see if I can add some of the missing tests detailed in the to-do part of some of those files. It will help me get better understand of whats going on in the code.

I think maybe I'm trying to do to much for the most part. WebApp QA stuff should ideally be left to them or at least be dependent on their tool sets. I believe its called the UAT phase which is the complete far end of the pipeline to were we are sitting. The whole screen shot and visual regression stuff. It would be good if I did have a QA dept (or the do it your self mentality) but I don't so I'm just going to have to make do with what I do have.

Ok, you can close this for now if you want or leave open for others. I'm going to focus on unit tests for the moment with an emphasis on postbacks events. To try avoid errors I will use the validators to make sure I get the data I need when using wf:q/1 or wf:mq/1. That should be good enough for now.

from nitrogen.

Good to hear.

If the start_other functionality doesn't work (as you mentioned in the login test, since it's looking for the login module), the other thing you could do to help would be to cheat by adding a module called something like web_start_test.erl that just sets a cookie or session variable like:

-module(web_start_test).
-export([main/0]).
main() ->
   wf:session(test_running, true),
   wf_test:start(fun() -> ok end),
   #template{file="your_template.html}.

From there, you can throw a little check in each page's main() function:

main() ->
   ?WF_IF(wf:session(test_running)==true, wf_test:start(fun tests/0)),
   #template{file=YourTemplate}.

That would give you some of the functionality you need here to have your tests explicitly run on your login page instead of a proxy page like test_login.

I would of liked to see the element get filled in by the value after the browser is launched.

That part is handled by the Setup argument in the test_X functions.

For example:

Setup = fun() ->
 wf:set(login, "Test_username"),
 wf:set(password, "Test_password")
end,
Assertion = fun() ->
 [Name, PW] = wf:mq([login, password]),
 case db_login:attempt_login(Name, PW) of
    {ok, Loginid} ->
        true;
    _ ->
        false
  end
end,
?wf_test_auto(attempt_login, Setup, Assertion).

Anyway, hopefully that all makes sense, and that I'm answering the right questions.

I will go ahead and close this now, but if you have more questions, feel free to ask.

from nitrogen.