Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Переписывание бедеверовских тестов #22

Open
arhadthedev opened this issue Oct 26, 2022 · 0 comments
Open

Comments

@arhadthedev
Copy link
Owner

bedevere, GH-...

  • Allows to run test__main__ with python -m unittest leaving pytest as an optional orchestrator with coverage grathering
  • Provides ready-to-use app, client and asyncio event loop so lesser harness inside a test body

The ultimate goal is to remove packages that bring no benefit comparing to builtin solutions. It makes maintenance easier by decreasing amount of layers to account and reduces amount of dependabot notifications.

Remove pytest-asyncio

строки неизменяемы, а потому если ссылаться на часть строки, она не изменится. Поэтому мы разделяем строку и источник строки. Источник строки обладает счётчиком и содержимым, часть строки же ссылается на источник, смещение и размер. То есть мы превращаем все строки в слайсы. Это позволяет не выделять память при операциях получения подстроки, что полезно, например, при рекурсивной итерации по подпапкам, когда мы извлекаем части имени файла.

проверить, даст ли выигрыш замена строки на объект-конкатенацию, всплывающий при склейке строк. Плюс: отсутствие копирования памяти.

Unify optional module handling in tests:

  • some modules assign None to module variables, others maintain ..._SUPPORT boolean constant
  • some modules have # NoQA and # pragma: no cover by these try-import blocks that hints
    it isn't the best practice
  • a couple of tests tried to import from inside a case doing raise unittest.SkipTest on failure

60 96 (59) 06 07

Окно браузера - это сразу fecer_browser::document_view с системным меню (управляетс приложением) и полосами прокрутки (управляется библиотекой). Остальное отрисовывает браузерный движок используя собственные средства макетирования.

Побочная гипотеза - написать весь браузер на скрипте - отметается из-за большого количества низкоуровневых примитивов. Но вот высокоуровневую интерфейсную часть так написать можно, предоставив дополнениям возможность это дело изменять. Возможно, можно даже воскресить Firefox API для этого дела, компилируя оптимизированный образ при запуске.

Хромовый API не покрывает эти нужды, так как не позволяет манипулировать интерфейсом.

То есть фундамент включает в себя:

  • сишные движок отрисовки, работы с файлами, сетью, мультимедиа

  • скриптовой движок, позволющий запукать изолированные среды (похоже на Electron, но более специализированный - пишите Node.js API поверх этого сами)

  • интерфейс и плагины, написанные на JavaScript и HTML (всё окно браузера - это одна HTML-страница и API для доступа к системному меню. Вкладки - это тоже HTML-страницы). Для изолирования страниц от интерфейса пробуем теневой DOM.

      self.test = loader.discover(self.start, self.pattern, self.top)
      elif self.testNames is None:
          self.test = self.testLoader.loadTestsFromModule(self.module)
      else:
          self.test = self.testLoader.loadTestsFromNames(self.testNames,
                                                         self.module)
    

asyncio/sslproto.py:

            if self._app_protocol_is_buffer:
                self._do_read__buffered()
            else:
                self._do_read__copied()

А почему протокол должно волновать, как там получает данные app_protocol? Он просто запрашивает данные и получает их.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant