pygame.tests and pygame.examples as packages.

-
As mentioned in pygame.test - moving testing forward the pygame project has moved the tests into the main pygame package(Lenard did all the work). *You* should consider installing the tests for your package too! All the reasons for doing so are listed at pygame.test - moving testing forward ... but I'll repeat them here too:
  • More people will run the tests.
  • people can run the tests to see if everything works in their own programs.
  • Can run tests on a persons computer to see if everything in pygame+ your program is working.
  • Which driver/function combination works, or works fastest? Run tests and find out.
  • Testing a py2exe/pyapp generated binary is much easier.
  • Reuse of our testing enhancements for their own tests.
  • Reporting bugs would be easier. Since everyone could run unittests, since they will be installed everywhere pygame is installed.
  • Result submission of unittests easy. This would result in a much larger base of computers running the unittests and submitting problems. This would be opt in of course.
  • Make the testing stuff more a library, than a framework.
  • Allow people submit unittests more easily. Since they won't require a source release of pygame to write unittests. eg people using a windows binary install of pygame, or a ubuntu binary install can run and submit unittests.
  • Make testing easier for people. The easier it is, the more worthwhile testing is.

>>> import pygame.tests
>>> pygame.tests.run()

However we also moved the examples into the main pygame package.

When the examples were separate as part of the source code distribution, or installable with a separate installer, many people did not install them. Then they had trouble finding the examples.

So now, people should be able to run examples like so:

>>> import pygame.examples.chimp
>>> pygame.examples.chimp.main()

Both of these things should make pygame easier to use, and also increase the quality a lot.

Comments

Post a Comment

Popular posts from this blog

Draft 3 of, ^Let's write a unit test!^

-
Image
So, I started writing this for people who want to 'contribute' to Community projects, and also Free Libre or Open source projects. Maybe you'd like to get involved, but are unsure of where to begin? Follow along with this tutorial, and peek at the end in the "what is a git for?" section for explanations of what some of the words mean. Draft 1, 2018/07/18 - initial draft. Draft 2, 2019/11/04 - two full unit test examples, assertions, making a pull request, use python 3 unittest substring search, "good first issue" is a thing now. Started "What is a git for? Jargon" section. Draft 3, 2020/12/12 - default branch name is main. What's first? A test is first. A unit test is a piece of code which tests one thing works well in isolation from other parts of software. In this guide, I'm going to explain how to write one using the standard python unittest module, for the pygame game library. You can apply this advice to most python pr...
Read more

Is PostgreSQL good enough?

-
Image
tldr; you can do jobs, queues, real time change feeds, time series, object store, document store, full text search with PostgreSQL. How to, pros/cons, rough performance and complexity levels are all discussed. Many sources and relevant documentation is linked to. Your database is first. But can PostgreSQL be second? Web/app projects these days often have many distributed parts. It's not uncommon for groups to use the right tool for the job. The right tools are often something like the choice below. Redis for queuing, and caching. Elastic Search for searching, and log stash. Influxdb or RRD for timeseries. S3 for an object store. PostgreSQL for relational data with constraints, and validation via schemas. Celery for job queues. Kafka for a buffer of queues or stream processing. Exception logging with PostgreSQL (perhaps using Sentry) KDB for low latency analytics on your column oriented data. Mongo/ZODB for storing documents JSON (or mangodb for /dev/null replacemen...
Read more

post modern C tooling - draft 6

-
Image
Contemporary C tooling for making higher quality C, faster or more safely. DRAFT 0 - 10/11/18,  DRAFT 1 - 9/16/19, 7:19 PM, I'm still working on this, but it's already useful and I'd like some feedback - so I decided to share it early. DRAFT 2 - 10/1/19, mostly additions to static analysis tools. DRAFT 3 - 10/4/19, updates on build systems, package management, and complexity analysis.  DRAFT 4 - 10/6/19, run time dynamic verification and instrumentation, sanitizers (asan/ubsan/etc), performance tools, static analyzers. DRAFT 5 - C interpreter(s).  DRAFT 6 - 11/6/19 , mention TermDebug vim,  more windows debugging tools, C drawing for intro. In 2001 or so people started using the phrase "Modern C++". So now that it's 2019, I guess we're in the post modern era? Anyway, this isn't a post about C++ code, but some of this information applies there too. No logo, but it's used everywhere. Welcome to the post modern era. S...
Read more