Python/DevOps

If you have to maintain a massive project, you probably have many fixtures in conftest file. And there is a problem; this file grows and grows. So, at some point, you decide to split this huge file into smaller files. But, py.test has to know the fixtures are keeping in these files. So, what you can do? I see three patterns here for this: import these guys inside conftest.py file create more conftest.py files use pytest_plugins Import fixtures inside conftest file You can for example do this: 1 2 3 4 5 6 7 8 9 from tests.my_fixtures.fixs1 import ( fix11, fix12, fix13, fix14, fix15, ... ) from tests.my_fixtures.fixs2 import ( fix21, fix22, fix23, ) from tests.my_fixtures.fixs3 import ( fix31, fix32, fix33 ) But, there are some problems with this approach. You import them in an explicit way, so if you create a new fixture, you have to remember to add this guy in the import clause. So, this strategy is not the best solution. If you have many fi

pytest-dbfixtures If you use pytest maybe you have heard about pytest-dbfixtures : Pytest dbfixtures is a pytest plugin that makes it a lot easier to set up proper database or storage engine for testing. Simply use one of provided fixtures that start predefined clean database server for your tests or creates server more tailored for your application by using one of provided factories. This plugin is very useful if you have integration tests in your project, and you want to perform tests on a database for example. You will find information how to use it in the documentation . Currently, the plugin supports: Postgresql MySQL Redis Mongo Elasticsearch RabbitMQ And recently, we have added support for DynamoDB . Here , you will find how to run DynamoDB on your computer. And, here we are. If you want to use it in production, you want to test it locally. dynamodb fixture If you still do not use pytest, go to the pytest page and read how to use it, now. If you want to

Watchdog is a python API and shell utilities to monitor file system events . I am using it for tasks like build sphinx docs or run tests after changes in file/directory. It's very easy to use. For instance, you are writing documentation and after each saving file you have to run command like "make html". So, why you don't this automatically?   Simple command: watchmedo shell-command --command="make html" --wait source What does it? Watchdog began to watch source directory. If something in this directory will be changed, then watchdog will run your command (make html). Simply, right? If you use Firefox you can install Auto Reload add-on. Auto Reload automatically reloads matching tabs when selected local files change. So, after saving file, your documentation will build automatically and Firefox automatically will refresh tab with documentation in browser, brilliant! You can also use patterns. For example, you want to run tests after saving file

Wstęp W ubiegłym roku pisałem o ultrajsonie , który wypadł bardzo dobrze. Przedwczoraj natrafiłem na bibliotekę ultramemcache , którą również postanowiłem przetestować i sprawdzić czy jest ultra. Do porównania wykorzystam biblioteki python-memcached oraz pylibmc . Pierwszy test odbył się standardowo poprzez odpalenie jednego procesu. Drugi natomiast z wykorzystaniem czterech procesów co znacznie przyspieszyło działanie. Jeden proces: python-memcached ultramemcache pylibmc Cztery procesy: python-memcached ultramemcache pylibmc Wyniki Testy wykonałem kilka razy dla każdego ze skryptów i wybrałem najlepsze wyniki dla danej biblioteki. Był to bardzo prosty test, ale da się zauważyć spore różnice w szybkości działania tych bibliotek. W przypadku jednego procesu ultramemcache poradził sobie najlepiej, chociaż pylibmc jest tuż tuż... Jeżeli chodzi o cztery procesy to pylibmc jest zdecydowanym zwycięzcą . Zachęcam do robienia swoich testów. Do sporządzen

Jeżeli korzystasz z Travis-CI do testowania swojego repozytorium na githubie oraz trzymasz paczkę na pypi , możesz w łatwy i prosty sposób dodać informacje na temat statusu do pliku README. Dzięki temu userzy będą widzieć czy wszystkie testy przeszły pomyślnie, jaka jest aktualna wersja paczki oraz jaka jest ilość ściągnięć. U mnie dla repo RandomWords wygląda to tak: Travis-CI W dokumentacji travis-ci znajdziesz informacje o tym co musisz umiejscowić w odpowiednim pliku. PyPI Osobiście korzystam z dwóch formatów. Markdown dla github oraz reStructuredText dla PyPI. Markdown : [](https://crate.io/packages/$REPO-NAME/) [](https://crate.io/packages/$REPO-NAME/) reStructuredText : .. image:: https://pypip.in/v/$REPO-NAME/badge.png :target: https://crate.io/packages/$REPO-NAME/ :alt: Latest PyPI version .. image:: https://pypip.in/d/$REPO-NAME/badge.pn

Trafiłem dzisiaj na framework splinter , który służy do testowania webowych aplikacji. Po przeczytaniu dokumentacji i przejrzeniu krótkiego tutoriala postanowiłem sprawdzić czy może mi się przydać. Framework poznałem u siebie lokalnie, wykonując testy na jednej z moich appek do testów, ale tutaj przedstawię to na istniejącej witrynie w sieci . Na początek garść informacji. Możliwości wykonywanie skryptów javascript bardzo proste api multi webdrivers (chrome, firefox, phantomjs, zopetestbrowser, remote) wsparcie dla xpath i css działające iframe i alerty działający ajax oraz asynchroniczny javascript    Instalacja pip install splinter Po jakże trudnej instalacji możesz wziąć się za testowanie web aplikacji. Poniżej znajduje się lista, które przetestuję na stronie sonyvegas : skorzystanie z wyszukiwarki próba skorzystania z kalendarza próba zalogowania na nieistniejące konto Pierwsze co musisz zrobić to stworzyć instancję przeglądarki, a robisz to tak: from sp