Testing

It’s been sometime since I wrote some python, and ended doing a bit of testing for a couple of routines which I ended up implementing. This post is more about me just condensing those ideas for python and how to do it in python, but the ideas are also a carryover from my other testing experiences, while using other languages and how my ideas for testing have progressed over time comparing some testing which I had done in some projects some years back. You can find a couple of more posts under https://www.tasdikrahman.com/blog/tag/testing/ where I have delved more into these topics. ...

This blog post is a continuation of this thread. On trying to write a spec for one of the rake tasks, when trying to invoke the same rake tasks within the same @rspec contexts, for different flows, weirdly the tests failed if I ran the whole suite, but would pass if I ran them separately. — Tasdik Rahman (@tasdikrahman) August 12, 2020 So for example # ./lib/tasks/foo_task.rake desc 'Foo task' namespace :task do task :my_task, [:foo, :bar] => [:baz] do |task, args| ... # does my_task ... end end Now if we try writing a spec a for it ...

This post is more of a continuation to this tweet One thing which I tried doing differently this time with one of my side projects is to do TDD from the start. Someone may ask why? It's just a side project no? (1/n) — Tasdik Rahman (@tasdikrahman) October 4, 2020 I have been building bhola in my free time, and one thing which I tried doing differently this time with it, was to practice TDD from the start. ...

First principles of testing stand for Fast Isolated/Independent Repeatable Self-validating thorough Bugs are introduced in the parts of code, which we usually don’t pay attention to, or places which are too hard to understand. Fast The developer shouldn’t hesitate to run the run the unit tests at any point of their development cycle, even if there are thousands of unit tests. They should run and show you the desired output in a matter of seconds ...

I have written about F.I.R.S.T principles of testing and TDD as a school of thought Probably an extreme opinion, but this is how Jeff Atwood puts it I Pity The Fool Who Doesn’t Write Unit Tests But what should you test? This I generally try to follow Test the common case of everything you can. This will tell you when that code breaks after you make some change (which is, in my opinion, the single greatest benefit of automated unit testing). Test the edge cases of a few unusually complex code that you think will probably have errors. Whenever you find a bug, write a test case to cover it before fixing it Add edge-case tests to less critical code whenever someone has time to kill. This will not only help you deliver and release faster, but will also make you more confident about your own codebase. ...

Software is eating the world, and so is the world of software development constantly changing. One way of developing a project would involve analysts figuring out the business requirements and sit for a few weeks if not months these requirements would be given out to the architects who would in case break the problem down into manageable chunks the chunks themselves would be then given out to the teams which would be the delivering the specific modules. Nothing, but a typical waterfall model scenario, coming with it’s obvious pros and cons. ...