Posts

Showing posts with the label testing

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...

ipython and doc tests. Cutting and pasting doctests into your shell.

Doc tests are a kind of literate programming for python. Where you type tests like you're typing stuff into an interpreter. In fact, it's easy to just type stuff into the interpreter and once you've finished playing around, copy the results from your terminal into a test file. This is a great, fairly low effort way of writing tests. However, what if you have written them in your source code file, and not in the interpreter? Ok, so you've written some doc tests and you want to paste doc tests into your interpreter ? With the normal python interpreter you can't paste doc tests in(I don't think). However the advanced ipython interpreter can. It has a special mode from writing doc tests. The command is called '%doctest_mode'. The %doctest_mode command allows you to paste in doc tests, into the interpreter... and have them run. The normal python shell fails at this, as the '>>>' is not valid python syntax. The ipython ignores the ...

bundling testing with your program... Ubuntu does too with Jaunty.

Ubuntu, with the latest release Jaunty, has a new application called "System Testing" which allows users to run system test. The program is called checkbox , and you can run it by selecting it from the menu: System -->Administration-->System Testing Now it's not a bunch of unittests... but instead it is a bunch of interactive tests. It's written in python too. It asks you some questions, and you need to perform the tests manually, and tell it if things worked correctly. At the end you can send the test results and the details gathered to the Ubuntu hardware database if you choose. As mentioned in ' pygame.test - moving testing forward ', ' pygame.tests and pygame.examples as packages ' and ' Distributed testing - the easy way. ' installing tests with your program lets way more people test your shit. So why not join numpy, cherrypy, pygame, ubuntu and others in installing tests with your program or package? >>> import yo...

Distributed testing - the easy way.

Distributed testing is easy. Include your tests in your package , and then whoever can install your package can install your tests. At pygame we have had much luck with including the tests with pygame. Then people can just do "import pygame.tests;pygame.tests.run()" It makes distributed testing easy, since now any of your users can run all the tests without having to have anything else installed(like source code, and a development environment). Then you need one machine to package your build for windows, and then it can be tested on lots of other windows machines. (same with mac). The builds are uploaded to the testing machines(that don't need a dev environment set up), and then tested there. Cherrypy and numpy(numpy.test()) also include tests with their downloads, and including tests is in the original unittest white paper. Testing bots. Then creating a network of test bots is trivial. Upload your package to them, or have them download it using http, and then get them...

pygame.test -- moving testing forward.

We are moving to including the tests with an installed python package... pygame. >>> import pygame >>> pygame.test.run() Why? Why include tests in pygame? Rather than only with the build process? 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 unitt...

timing and unittests - graphing speed regressions/improvements

Are there any python tools which allow you to run timing tests inside of unittests, and then see a useful report? I'd like to see a report of how long each timing test took, and also see differences between runs. When comparing two runs I'd like to see visually which is faster. Timing information is a very important thing to time for gui applications like games, and websites. As so many machines are very different, it's useful to be able to time things as they run on different machines. A game or website can quite easily run 10-30 times slower even on machines with the same CPU. Many other factors like OS, hard drive speed, available memory, installed drivers, directx/opengl/X/frame buffer, different browser speed, different installed versions of libraries or plugins like flash. Testing all these things manually is almost impossible, testing them manually every time something changes is definitely impossible. So I want to use this tool pygame unittests specifically, an...