Welcome to domonic Discussions!

[byteface]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[SUCHITRAGIRI]

Hi, I am Suchitra, just explored the project and feeling wondered how beautifully it managed. Looking forward to doing some contributions.
Hope will do:)
Also, if you don't mind, give some suggestions where should I start working!

[byteface]

Hi @SUCHITRAGIRI that's incredibly brave of you. I'm unsure of your skill level.

The best ways to support domonic are to add docstrings, add 'typing' where it's missing or add unit tests. As those 3 things indirectly build everything else. The DOM is still largely undocumented also which drives traffic to the repo... https://domonic.readthedocs.io/

maybe try adding some docstrings to this class for example?....
https://github.com/byteface/domonic/blob/master/domonic/geom/shape/shapes.py

or learn how to publish the docs and use some existing units tests as examples in the docs.

basically. all functions need an assertion. if you turn a print into an assertion succesfully that's a good PR. But be warned this can throw bugs and will expose edge cases.

There's lots of things up for grabs. i.e the entire CSSOM was stubbed out in the style.py class and I won't even get to that for months. So up to you. depends on how much you want to take on.

also if you see anything missing from here... https://developer.mozilla.org/en-US/docs/Web/API/Document then feel free to raise a ticket.

thanks for stopping by :)

[SUCHITRAGIRI]

Hi, @byteface
Actually I know Java but didn't work with Python, and also I am new to open-source projects.
I want to learn unit test, can't I do that ?
Suggests some resources or insights!

[byteface]

Unit tests are easy. You already kinda do it when you run your code. That's testing it.

But we run our code from a test.py file instead of directly to put 'assertions' in that make sure it stays that way.

For example we make a test

def test_myClassExists(self):
	d = MyClass()
	assert type(d) == MyClass

And run it. It will fail. We always make failing tests first. Now we have to write some code to make that pass.

Class MyClass:
	pass

Now we import it and the test will pass. But what's cool is. If anyone EVER changes the name or type of MyClass. They will be warned and won't be able to build. Sometimes this means re-writing the tests to new conditions. But see how it stops mistakes.

Also see how it caused you to write the code. The test 'drives' the production of the code.

Others can now only commit code which does not break existing code. There's lots of testing frameworks to facilitate this.

99% of people including me often do it wrong and write the tests afterwards. This can lock in bad behaviours and doesn't very well test exceptions and edge cases before they happen.

Anyway with that in mind. You can end up with lots of tests. I use linux so personally put these in a 'Makefile' to run them for me. (But that may not work on PC)

Whenever I've been coding for an hour. I run the full suite of tests to make sure everything still works.

But during development I constantly copy and paste single test from the Makefile for example to test a single module. Or even drill down to calling one test function directly.

I hope this helps.

Some further reading re domonic specifically…

One problem with domonic is many of the tests are lazy as I stubbed out a HUGE dom. So they just print(result) rather than assert several things. This is really bad. I'm going back over when I can to tighten things up and put assertions in.

domonic is setup to automatically run the test on different versions of python and operating systems here…

https://github.com/byteface/domonic/actions

Which allows anyone to see the results of their code changes and if the tests have passed.

Once you have tests you can also do something called 'coverage' which tells you what perecentage of your code is covered by a test. It does this by recording the lines of code it executed during testing. This can show you where there is code that has no tests so is liable to breaking in production under certain edge cases. Again this is why my 'print tests' are bad as they say the code is covered which it is. But it is not asserted. Getting max coverage and testing up front is the ambition or goal.

[byteface]

to get a list of css classes used in a page:

domonic -x https://www.hackernews.com //*/@class | sort | uniq

[byteface]

I just tried this with domonic and works really well...

https://github.com/reloadware/reloadium