Custom template tags not covered #36

Activity

1. PamelaM commented on Jan 30, 2017

   

   PamelaM

   on Jan 30, 2017

   Collaborator

   More actions

   Thanks for your issue report. There have been a number of similar reports. Late last night I found a fix for at least one of the potential initialization issues. I expect to create a PR with that fix tonight
2. PamelaM commented on Jan 31, 2017

   

   PamelaM

   on Jan 31, 2017

   Collaborator

   More actions

   Could you try with PR #38?
   Thanks.

   Background:
   Since version 1.8, Django has been deferring initialization steps later and later in the process.

   Since these changes are all internal to Django, they are not always mentioned in the various release notes, so there's a bit of "whack a mole" trying to find issues. And one-time initialization order issues are very hard to write unit tests for :( (See PR #37 for an attempt to test these paths)
3. jclgoodwin commented on Jan 31, 2017

   

   jclgoodwin

   on Jan 31, 2017

   Author

   More actions

   No luck with #38. Commenting out lines 166 and 169 of plugin.py fixes the problem for me, though I don't understand why.
4. PamelaM commented on Jan 31, 2017

   

   PamelaM

   on Jan 31, 2017

   Collaborator

   More actions

   @jclgoodwin Thanks for trying. I'll dig in some more and get back to you with another attempt.

   <grumble>django gets more efficient at startup ... and more confusing</grumble> :)
5. PamelaM commented on Feb 1, 2017

   

   PamelaM

   on Feb 1, 2017

   Collaborator

   More actions

   @jclgoodwin Do you have a working example I could test against? Or at least your settings.TEMPLATES configuration?

   I've added a template tag to my "insane_integration" test branch, but it works correctly.

   Commenting out those two lines will prevent check_debug from executing. check_debug validates that the templates are (a) only using the standard Django Template Engine and (b) said engine is configured to be in debug mode.
6. jclgoodwin commented on Feb 1, 2017

   

   jclgoodwin

   on Feb 1, 2017

   Author

   More actions

   Yes: https://github.com/jclgoodwin/bustimes.org.uk/blob/master/buses/settings.py#L132
7. beda42 commented on Feb 27, 2018

   

   beda42

   on Feb 27, 2018

   More actions

   Hello,

   Just my two cents. I am seeing this problem still with version 1.5.0 and Django 1.11.7 and coverage 4.4.1.

   My observation is that if the custom tags are loaded into a template, it does not break anything. But when they are used, it leads to the whole template being marked as not covered at all.

   Any idea how I can try to debug it? Unfortunately the project I am working on is not yet public.
8. TauPan commented on May 5, 2019

   

   TauPan

   on May 5, 2019

   More actions

   I've just noticed that https://github.com/TauPan/pytest-django-xdist-cov-bug also seems to reproduce this issue. At least I noticed that I see no coverage for home.html which uses a custom template tag. (Thinking about filing pytest-dev/pytest-cov#285 against this repo, too, but that's still undecided.)
9. TaylorSMarks commented on Apr 18, 2021

   

   TaylorSMarks

   on Apr 18, 2021

   More actions

   This is still an issue for me using:

   • django 3.11
   • python 3.9
   • coverage 5.3
   • django-coverage-plugin 1.8

   What workarounds are available?
10. TaylorSMarks commented on Apr 19, 2021

    

    TaylorSMarks

    on Apr 19, 2021

    More actions

    I tried just adding # pragma: no coverage comments to the lines which were getting flagged as uncovered but I knew were obviously getting covered, IE, function definition lines, but that resulted in it skipping measuring whether the bodies of those functions were covered, effectively meaning the file was completely excluded.

    So I spent the past 3 hours putting way too much effort into learning about the Coverage API and writing this function which is janky but seems to work for me:

        def fixTagCoverage(self):
            from coverage import CoverageData
            cd = CoverageData()
            cd.read()
            arcData = {}
            for filename in cd.measured_files():
                if not 'tag' in filename:
                    continue
    
                arcsToAdd = []
                priorLine = -1
                with open(filename) as f:
                    for i, line in enumerate(f.readlines(), start = 1):
                        if line.startswith('from ') or line.startswith('register = Library()') or line.startswith('@register.') or line.startswith('def '):
                            arcsToAdd.append((priorLine, i))
                            priorLine = i
                arcsToAdd.append((priorLine, -1))
                arcData[filename] = arcsToAdd
            cd.add_arcs(arcData)
            cd.write()

    It's not documented anywhere, but if you're measuring branch coverage, you must add arcs. Trying to add lines in instead gives back an error message.

    This is all executed as part of a larger customer Django management function I've written... here's the lines around the one where this function is called:

        def runPythonTestsWithCoverage(self):
            omitS = f'--omit={",".join(self.omitFiles + [d + "/*" for d in self.omitDirs])}'
            run(['coverage', 'run', '--branch', "--source='.'", omitS, 'manage.py', 'test', 'myapp']).check_returncode()
            self.fixTagCoverage()   # <<<<<<<<<<<<<<<<<<<<<<<<<<< Where I call the function I just wrote
            run(['coverage', 'report', omitS, '-m', '--skip-covered', '--fail-under=100']).check_returncode()
            run(['coverage', 'xml', omitS])