[RFC]GSoC 2018 Test framework improvement

[Su Billy]

Hello developers, 

My name is BING-LI SU from Taiwan, you can simply call me Billy.

Background

I'm an undergraduate student at National Chiao Tung University, major in Computer Science.

I have been contributed to several open source projects for one year, such as CDNJS, pyqtgraph, and I host my own project using Tornado Web to build a simple digital signage system which contain a little bit unit test, CI, and docker image for fast deployment.

I have know Django when I chose the framework of the digital signage, but I haven't used it util these few days, knowing that Django is a more sophisticated and handy framework compared to Tornado. In my opinion, the best way to be familiar with a project is to understand the test of the project (if there has one), therefore I choose test framework as my proposal idea.

Ideas

I'd like to add some new feature to the test framework, it is mainly about provide some groups of common used tests for user to choose, and maybe provide hook function to add their own test before, after, during each group of tests.

Plan

Here is my draft plan to achieve above ideas

1. To make me better understand the whole test framework, I will briefly trace the test framework in May

2. Find out and discuss with mentor about how to group up the tests and what this feature should look like.

3. Implementation and discuss with mentor once or twice a week.

Thanks for any suggestion or comments, i.e: I should start to trace which part of test framework? The idea has some problem...? etc.

sincerely

Billy Su

[Josh Smeaton]

Hi Billy,

This plan sounds more like a plan for a plan. If you're serious about wanting to participate in GSoC, then you need to have **specific** ideas and goals. By this, I mean your proposal should be able to be picked up by anyone and implemented. You're missing any actual feature proposals. To be successfully chosen, what you'd need to demonstrate is that you have a good understanding of how things already work, and the problems that people face. You'd also accompany your proposal with code/test examples of **how things are now** and **how things will be** once you've completed the project.

Regards,

[Joe Tennies]

Django does have a testing framework that's based on the unittest module from Python standard library. That stated, I've seen people use nose and other frameworks in the past. (More info at: https://docs.djangoproject.com/en/2.0/topics/testing/)

I feel there is always a need for better helper utilities to make writing tests so easy that people have no excuse NOT to write them. That stated, the GSoC's that have been accepted in the past have been very specific about what they are proposing and milestones as to what will be done and when. There is no time in schedule to discover or define the scope. Obviously, there will always be issues that come up and changes are inevitable, but Django has a limited number of slots and wants to choose projects that not only provide good benefits to the project but are likely to succeed as well,

Hopefully this is helpful. You may be on the right track, but you'll have to not only sell on what you will do but that you're the correct person to do it and you understand the scope.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ad1d498b-c14b-40a5-9ca0-fee65814ed59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Su Billy]

Dear Josh and Rotund,

Sorry for late reply, since I was surveyed for what concrete feature I want to implement.

According to some ticket, such as #6712 #17365 #13873, some developer want to define their own test suite instead of let test runner discover and construct one, and therefore the #tagging-tests was implemented, but if we need to change the test suite, we need to add or edit tag in many place in the test script, therefore, I came up a new feature is that provide a way to let developer define their frequently used tests as test suite in a file.

Although it already exists ``tag`` for developer to categorize tests, within this feature developer could have a more convenient way to define the test suite for their project to let their user easier to run test without need to memorize which tags or test modules needs to specified in command line, because it already defined in test suite file. 

The test suite file may be written in JSON format or YAML fomat(I don't know which one is better)

eg:

There are two apps in this project, ``mysite`` and ``polls``.

The structure of the project may be

├── db.sqlite3

├── manage.py

├── mysite

├── test_suite.json

│   ├── __init__.py

│   ├── settings.py

│   ├── tests.py

│   ├── urls.py

│   └── wsgi.py

└── polls

    ├── admin.py

    ├── apps.py

    ├── __init__.py

    ├── migrations

    │   └── __init__.py

    ├── models.py

    ├── tests.py

    ├── urls.py

    └── views.py

The content in test_suite.json is

{

  "Fast test": {

    "mysite":{

      "tag": ["fast", "quick"]

      "tests": ["urls", "views"]

    },

    "polls":{

      "exclude tag": ["low", "detail"]

      "tests": ["template","login"]

    }

  },

  "Detail test": {

    "mysite":{

      "tests": "all"

    },

    "polls":{

      "tests": "all"

    }

  }

}

The usage of running these suite is simply use

./manage.py run test --suite="Fast test"

The ``mysite`` and ``poll`` are the app names in a project, tests field in test suite file may be module, TestCase class or even single test in TestCase. As for the ``tag`` and ``exclude tag`` which uses the tag decorator in original tag system.

This feature seems to have many behaviors similar to original tag, but I think this test suite feature will make developer easier to define their suite without add or edit many tags in script.

Sincerely 

Billy Su

Rotund於 2018年3月17日星期六 UTC+8上午4時38分16秒寫道：