Sure, here's some thoughts: Inheriting from TestGitRepo means it gets all the test_* functions, so when I ran nosetests, it ran a lot of TestGitRepo.test_* tests too, which we don't want to happen. So I'd remove that inheritance. You probably will have to duplicate the setup_with_tools() function in this file then.
Actually, inheriting from _TestCase in forgegit/tests/functional/test_controllers.py might be a good option. It has some setup functions you can use (so you don't have to duplicate setup_with_tools) and it doesn't have any test_* functions. The super() call is supposed to use its own name, like super(TestMergeRequestsSection, self).setUp() Not sure if that makes a difference here or not. merge_request() is a function but you don't have parenthesis on `mr= self.merge_request` so that function isn't running. I realized what happened earlier when I didn't see the "Tickets" section in the HTML output of the tickets test! When I was trying this test now, I got a similar situation where the "Merge Requests" section isn't in the HTML output at all either. So I looked in the 'test.log' file (where logging goes to during tests) and saw "Error rendering section MergeRequestsSection: ..." with error details. So these sections trap errors and log them, instead of letting the whole page error. So looking at the test.log output can help see those errors when they happen. You may need to run ThreadLocalODMSession.flush_all() after creating the merge request object. That is a common test pattern we have when tests create something and then need to view it. (Mainly needed in tests, since regular web pages will flush at the end of each request). Hope that helps, let me know how far you get, and I can look at it some more if needed :) On 7/27/18 9:11 AM, Deshani Geethika wrote: > Hi Dave, > > I have started to write a test case for Merge Requests Section. For that I > have followed ForgeGit tests but it doesn't work for me. I was trying to > create a merge request and see whether it appears in dashboard. > > I've pushed the code into my fork > <https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/96613c7854d116130455a343c814e853c2b5d812/>. > Can you kindly take a look at that? Also, please let me know any debugging > process can be done for methods called internally when creating a merge > request. > > Regards! > > On Tue, Jul 17, 2018 at 11:19 PM Deshani Geethika <deshanigeeth...@gmail.com> > wrote: > >> Hi Dave, >> >> Thank you for sharing these valuable information. I have added a merge >> request <https://forge-allura.apache.org/p/allura/git/merge-requests/269/>. >> Please review it and let me know any further improvements. >> >> Regards! >> >> On Mon, Jul 16, 2018 at 9:54 PM Dave Brondsema <d...@brondsema.net> wrote: >> >>> On 7/16/18 9:49 AM, Deshani Geethika wrote: >>>> Hi Dave, >>>> >>>> I have tried with adding above lines, but still doesn't work. Can you >>> take >>>> a look at my implementation >>>> < >>> https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/a7ddd0c0bbcfe89cb14fc5214deff168cbb20477/ >>>> >>>> ? >>>> >>>> Thanks! >>>> >>> >>> Here's some debugging process I did, you can try it too: >>> >>> Tests use the MockSOLR class instead of a real solr instance (so that you >>> don't >>> need solr to run tests). I knew that, so I started by going to >>> MockSOLR.search() and putting in some print statements to debug it. At >>> the >>> beginning of search() I added: >>> >>> print q >>> print fq >>> >>> And inside the "for obj in self.db.values():" loop, I added "print obj" >>> >>> My idea was to see what query is happening and what the stored objects >>> are, and >>> see what's not working. I ran just the single test with `nosetests >>> >>> allura.tests.functional.test_personal_dashboard:TestTicketsSection.test_tickets_section` >>> I noticed there was a 'project_id_s' in the search query, and there >>> shouldn't >>> be. But after a bit of trial & error to see what was happening, I >>> realized that >>> was coming from a "update_bin_count" background task, and that wasn't >>> related to >>> the test really. >>> >>> So I commented-out the tasks M.MonQTask.run_ready() to avoid all the >>> background >>> tasks for now and did it again, and there wasn't any of my print >>> statements >>> occurring. So the dashboard ticket search wasn't even happening it seems. >>> >>> Then I printed the "response.html" variable to look at the whole >>> dashboard page >>> and I didn't see the Tickets section in it at all. So indeed, that >>> section >>> isn't included in this test at all for some reason. >>> >>> Hopefully those are some helpful examples for this particular situation >>> and also >>> ideas for how to debug high level (like "is it even running?") and low >>> level (to >>> see where things might be not working). >>> >>> Next step of course is to figure out why in this test the dashboard >>> section >>> isn't even running. I'll let you work on that. My general strategy is >>> to put >>> debugging in various places to confirm if things are running with the >>> right >>> values, or where they aren't, and narrow down to the spot where it goes >>> wrong. >>> >>> >>> -- >>> Dave Brondsema : d...@brondsema.net >>> http://www.brondsema.net : personal >>> http://www.splike.com : programming >>> <>< >>> >> >> >> -- >> *Deshani Geethika* >> Undergraduate at Department of Computer Science and Engineering >> Faculty of Engineering - University of Moratuwa Sri Lanka >> LinkedIn <https://www.linkedin.com/in/deshanigeethika/> | GitHub >> <https://github.com/deshanigtk> | Mobile - +94776383034 >> >> > -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><