Manual Test Framework

[Ian C]

Hi Peter,

thanks for your help over the past few days.

I have just pushed a new version of my test editor come test framework into the odflenses branch.

It incorporates the new editor api.(Franz - I looked for your editor which I remember had hooks for standard editing functions (not sure where it went).... but that is more than I need just yet)

I make it work by having a directory link to the corinthia-editor js files.

so in the public/app/js directory

ln -s ../../../../../../corinthia-editor/build/src/ editor (or other OS equivalent)

Then it can find the editor files.

Of course it does not do anything sexy yet. Adds and deletes Xs at the start of the document.
(Folks - for sexy check out the demo in corinthia-editor/demo).

At the moment it provides a framework for me to build on - input odf and docx documents, convert them and see what is going on inside them, edit (add Xs), save and convert back to the orignal form.

I intend to add more and more complicated test scenarios in an automated way. Similar to the editor testharness.

And of course poke around with by production coverage analysis.

So this is now close to the framework I need and can continue to develop the odf conversion side of things too.

--

Cheers,

Ian C

[Peter Kelly]

Hi Ian,

I just tried to compile your latest changes on the odflenses branch at it looks like you might have forgotten to commit some files - specifically in the coverage. When running cmake I get the following error:

CMake Error at DocFormats/CMakeLists.txt:33 (add_subdirectory):

  The source directory

    /Users/peter/corinthia/corinthia-docformats/DocFormats/coverage

  does not contain a CMakeLists.txt file.

If I remove that directory from the CMakeLists.txt, it still has a problem because of the $<TARGET_OBJECTS:coverage>. Even after removing that, the sources are still trying to find files that just aren’t there (ProductionCoverage.h). So I think if you just make sure those files are in the repository then it will work.

BTW, there’s a change I want to make to both DocFormats and corinthia-editor which is going to affect a large number of files - changing the “uxwrite-“ prefix to “corinthia-“ on all our special classes, like those used for footnotes, bookmarks, references, etc. I can do the change in both master and odflenses do avoid major merge issues later on, but wanted to hold off to get your ok first to make sure your latest changes are in so you don’t undergo merging hassles. Let me know when it’s in a state where I can go ahead and make the commit, and once it’s done you can continue on from there.

I’m also making good progress on an interactive web-based editor, and hope to have something cool to show in the next few days.

--
Dr. Peter M. Kelly
kell...@gmail.com

http://www.kellypmk.net/

PGP key: http://www.kellypmk.net/pgp-key

(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

--
You received this message because you are subscribed to the Google Groups "CorinthiaTeam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to corinthiatea...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ian C]

Sorry Peter, I have just pushed the ProductionCoverage files. Hope that is all that is needed.

And as I said in my comment when I pushed them we can probably do it externally anyway. I'll see how I go.

And remove them later possibly?

--

Cheers,

Ian C

[Peter Kelly]

On 12 Mar 2016, at 10:22 AM, Ian C <i...@amham.net> wrote:

Sorry Peter, I have just pushed the ProductionCoverage files. Hope that is all that is needed.

Thanks Ian, it compiles for me now. I’ve also fixed a few warnings in the code.

And as I said in my comment when I pushed them we can probably do it externally anyway. I'll see how I go.

And remove them later possibly?

I think leave it in there for now, if it’s more convenient for you. Ultimately I think it would be best to have hooks in place so you can e.g. tell the API whether you want coverage info generated, and if so, where. But at this point while it’s separate from the master branch I don’t see a problem with it.

Can I assume I’m safe to go ahead with my proposed change of the uxwrite- class prefix to corinthia- that I mentioned in my earlier mail? (I’ll do this in both branches to avoid merging headaches).

[Ian]

Hi Peter,

On 13 Mar 2016 12:37 am, "Peter Kelly" <kell...@gmail.com> wrote:
>>
>> On 12 Mar 2016, at 10:22 AM, Ian C <i...@amham.net> wrote:
>>
>> Sorry Peter, I have just pushed the ProductionCoverage files. Hope that is all that is needed.
>
>
> Thanks Ian, it compiles for me now. I’ve also fixed a few warnings in the code.
>
>> And as I said in my comment when I pushed them we can probably do it externally anyway. I'll see how I go.
>> And remove them later possibly?
>
>
> I think leave it in there for now, if it’s more convenient for you. Ultimately I think it would be best to have hooks in place so you can e.g. tell the API whether you want coverage info generated, and if so, where. But at this point while it’s separate from the master branch I don’t see a problem with it.
>
> Can I assume I’m safe to go ahead with my proposed change of the uxwrite- class prefix to corinthia- that I mentioned in my earlier mail? (I’ll do this in both branches to avoid merging headaches).

Sure go for it.

>
> --
> Dr. Peter M. Kelly
> kell...@gmail.com
> http://www.kellypmk.net/
>
> PGP key: http://www.kellypmk.net/pgp-key
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>

[Peter Kelly]

On 13 Mar 2016, at 9:55 AM, Ian <ham...@gmail.com> wrote:

Hi Peter,
On 13 Mar 2016 12:37 am, "Peter Kelly" <kell...@gmail.com> wrote:
>>
> Can I assume I’m safe to go ahead with my proposed change of the uxwrite- class prefix to corinthia- that I mentioned in my earlier mail? (I’ll do this in both branches to avoid merging headaches).

Sure go for it.

Done. You’ll see a large number of files change when you pull, but the vast majority of these are test cases. I don’t expect there’ll be too many difficulties merging, depending on how much you’ve done since your last push. If you haven’t made any changes then the pull will go cleanly.

[Ian C]

On Sun, Mar 13, 2016 at 11:18 PM, Peter Kelly <kell...@gmail.com> wrote:

On 13 Mar 2016, at 9:55 AM, Ian <ham...@gmail.com> wrote:

Hi Peter,
On 13 Mar 2016 12:37 am, "Peter Kelly" <kell...@gmail.com> wrote:
>>
> Can I assume I’m safe to go ahead with my proposed change of the uxwrite- class prefix to corinthia- that I mentioned in my earlier mail? (I’ll do this in both branches to avoid merging headaches).

Sure go for it.

Done. You’ll see a large number of files change when you pull, but the vast majority of these are test cases. I don’t expect there’ll be too many difficulties merging, depending on how much you’ve done since your last push. If you haven’t made any changes then the pull will go cleanly.

merged and everything built okay.
 

--
Dr. Peter M. Kelly
kell...@gmail.com

http://www.kellypmk.net/

PGP key: http://www.kellypmk.net/pgp-key

(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

--
You received this message because you are subscribed to the Google Groups "CorinthiaTeam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to corinthiatea...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Cheers,

Ian C

[Ian C]

Hi Peter,

I just pushed an updated version of my test framework.

To make it run there are a couple of steps.

It needs the corinthia-editor to be an a parallel checkout and to have been built ,as described earlier in this email trail.

And the editor directory to be linked...

Then run npm install

npm start as before..

On the opening page there is an AutoTests button... that is what I have been playing with... I will remove the Manual Tests soon I think.

Click the button.

There are a couple of tests, one to insert text from to a seed document.

The other to delete text.

There is a tests directory under which the tests can be defined.

There are two key files in a test directory. runtest.js - the script to execute.

And test.json which is meant to be meta data for the test. At the moment the only real things are the name and the seed document.

In a test script if you add

  autosave = false;

then it will pause so you can see what happened.

The top level list also provides links to the json and a drilldown table to the before and after on the test.

Once it has been run of course - need to manage that.

I will be using the json files to verify the test cases.... real soon now.

And extending....

But thought I'd push what I have for the moment. And Franz there is a corinthiaProcess.js file that use used to call corinthia, if you're interested.

The thing is really a nodejs http server calling corinthia.

Anyway, I've had enough for today.... catch you later...

--

Cheers,

Ian C

[Peter Kelly]

(replying this time to the group, not just Ian - would be nice if google groups automatically set to the reply-to address properly…)

Hi Ian,

Finally got round to having a look at this… been busy with some other stuff this week.

In the auto tests, I found that the insertAtStart worked, but the deleteFromStart one failed. The error I got was "Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.” What’s really weird is that in the stack trace, all of the frames are in require.js - looking at the test file it’s just calling moveRight() and deleteCharacter() so I would have expected the exception to have occurred within the editing library. Perhaps it actually is, but the stack trace is incorrectly reporting require.js due to some aspect of the way it’s loaded. I observed this behaviour in Chrome, Firefox, and Safari.

I like the idea of the tests.json having the expected results as part of the test items. This does centralise things a bit more and avoid the need for a “testname-expected.html” file like in the editor tests. As long as the actual tests themselves are kept simple, this should work fine. Since the switch to typescript I’ve been considering moving the code for all the tests into typescript modules, so they can be type checked properly - any thoughts on the pros/cons of this?

Also in the manual editor (after you upload a .odt) I get a ReferenceError for ‘autoEdit’.

BTW, I just realised that I forgot to push the changes I made replacing “uxwrite-“ with “corinthia-“ as a CSS class prefix a couple of weeks ago. I’ve reapplied the commit on top of the latest odflenses commit and pushed that now. Make sure you pull before making any changes to the C code to avoid conflicts.

--
Dr. Peter M. Kelly
kell...@gmail.com

https://www.pmkelly.net/

[Ian C]

Thanks Peter,

I just picked up those changes as I just pushed an update to the Auto Tests.

They now automatically save, are verified and feed back status to the test list.

There is also a merged table view to show graphically what the changes were.

They at least work for the couple of noddy tests I have created.

So now have a much better basis to create more tests etc

RE the manual test... it is in a state of flux... I may just drop it.

And re the deleteFromStart test... yeah, I made it work by changing the test to...

function autoEdit(api) {
    api.cursor.moveRight();
    api.cursor.moveRight();
    api.cursor.moveRight();
    api.cursor.moveRight();
    api.cursor.moveRight();
    api.cursor.deleteCharacter();
    api.cursor.deleteCharacter();
    api.cursor.deleteCharacter();
    api.cursor.deleteCharacter();
    api.cursor.deleteCharacter();
}

At first I was just calling deleteCharacter at the start but that leads to badness. Because the delete is a backspace delete?

I also had some issues with the other test and inserting a space. But will come back to that,

And as for changing to Typescript... Maybe, I can see the advantages. But it has just taken me some time to bash this standard js into a working order.

I see there are some Angular Typescript things too.

But I think for the moment I will press on with what I have.