I’ve been writing about the basics of using python test frameworks for over a year now.
- Still todo
- Big picture
- My history clouding my vision
- My code is done. Now how do I write unit tests for it?
- Short answer
- My part
Still to do
There is still lots to cover:
- integrating with continuous integration (CI)/continuous testing servers
- xml/json output to integrate test reports into web pages
- incorporating test instruments as resources
- when and how to distribute your tests
- organizing test code
- … lots of other topics that will come along as I explore more …
Stop. Back up. Big picture.
I think I need to back up and look at the big picture for a while.
I’ll tell you why in just a minute.
I’m going to get started on a series of topics to round this out a bit before I go nitty gritty into details again.
- The role of testing in the design and development cycle
- Types of tests
- functional tests
- acceptance tests
- unit tests
- regression tests
- performance tests
- Test Driven Development (TDD)
- Interface design and it’s affects on testability
- Who runs the tests, and how often.
- How company structure affects software design and testing
- How software structure/design affects testing
- Designing for test
- Different types of people writing tests
- Different roles of test writers
- The importance of not removing ‘thinking’ from the process
- Lean Development Processes
- Where does Agile fit in
- Test case design
and perhaps some seemingly trivial (but hugely important for efficiency) topics
- the importance of a decent editor
- learn how to navigate your code quickly: symbol search, grep, ack, etc.
I hope this doesn’t end up being too long of an excursion away from in depth tutorials.
However, I do think it’s important information.
Although there is a lot of this information already on the web, I’ve got my own thoughts on the matter based on my own experience and what I’ve observed both in industry and in open source efforts.
I will get back to the nitty gritty tutorials.
I just want to give a little perspective first.
My history clouding my vision
I’ve been writing unit tests and functional tests (acceptance tests) as part of my development process for over a decade.
I read about test-first programming when I started following the writings around extreme programming (XP), pragmatic programming, lean software development, agile development processes, scrum, kanban, etc. starting somewhere around 2000.
I’ve read so many books and articles, and used so much of the practices, for so long, that it seems obvious to me.
Of course testing is crucial.
Of course testing has to be part of the design and development process from the get go.
It really didn’t occur to me that of course people new to development wouldn’t know all of this stuff.
It also has become obvious in my work career that many developers learn the skill on the job, perhaps coming from a EE background, and have not read lots of software development books and blogs.
“My code is done. Now how do I write unit tests for it?”
Writing unit tests in Python: How do I start?
I completed my first proper project in Python and now my task is to write tests for it.
Since this is the first time I did a project, this is the first time I would be writing tests for it.
The question is, how do I start? I have absolutely no idea. Can anyone point me to some documentation/ tutorial/ link/ book that I can use to start with writing tests (and I guess unit testing in particular)
Any advice will be welcomed on this topic.
Short answer: It depends.
It depends on what you know already, and the specifics of your situation.
What are you trying to test? Why didn’t you use TDD? Are there requirements in place? Who wrote the requirements? How big is the organization? Do you have a QA team? Is this code mission critical? What are the consequences of it NOT working? …
So many questions need to be answered before answering the question “How do I start?”.
I’m sure the original asker of the question has it all figured out by now.
However, the question gets at a couple daunting topics in testing.
There are people trying to do the right thing. But they don’t have the right information yet.
We can’t freak them out by telling them to go read 5 200+ page books and about 3 dozen blog posts to get them up to speed.
I’ve learned a ton from my experience, from books and blogs and articles, and most importantly from some amazing developers, managers, testers, application engineers, (and even EEs) I’ve worked with over the years.
So I’m going to try to do my part.
I’m going to try to cover some of these topics.
And I’m really going to try to do it in a way to not freak people out.
It doesn’t have to be complicated.
Unless of course you are trying to get people to hire you as a consultant.
Then perhaps complexity works in your favor. (That was a joke.)
I’m writing this blog to try to push software development forward an inch or so. Trying to pay back the community that has shared so much knowledge with me over the years.
Please know that I’m doing this with a good goal.
If you are knowledgeable on these topics already, I encourage you to point out places where you think I’m mistaken. Debate is great.
Let me know if you have topic ideas.
- stuff you wish you knew before you got started
- stuff you wish your collegues knew
- stuff you want to know more about
Thanks for making it to the end.