Re: Fixing a poorly written Django website (no unit tests)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJU+fpuAAoJEC0ft5FqUuEhDFEQAKgCRVMY68x4fTsS472cRjD8
LnYXN7xrSC8XiZhv9vxoci5693mLsFF8t5kh7ByMmTU6YpHKcFA1RLC/s3ZxncTI
fgRahGIJv3ka4E6VzPh4zHmTQBdLtw6k+vE4HOXrgZITTcs8a+pC+oxpQEhgH13W
OZeefTth9818DtkGUuPTAGPDsOWLJfQINx8DTK3ziWKZPso57fW9M9bKXcyxwpgD
FofMO9ey+gXm6CdAKEwgF/aXfEnkq7X/pikmMr+48aRMrEKJUlNW3SrGwfENhbUE
9AkW7osWNeaT0Re8SSpp99psa4s3VC+vcpseHAzAs7oge4Ky9pwWMo12BpFVSHW7
Ncfp3RJQNpfIVKJUAQUCXDO3W30pK65XmcJJVFTc6k82zLierhUk6kDVIdvVqeIL
TQ0mSPB1wd7lyFFbS5Vud7aMb5FWIFifh0vOPdGGaQrmpqZfIGaI1NibWbNl3+ox
SrsiLfeDfETa/MgQTwtVV8rFJDW9QhPlqAZsnWTjWrGOwRnf83RT0/F/wuiKQgmo
4KUSWvWpvKVh5W83ex1Xligksqdeqo48tHTXxDF5HPDlXZvsEOuYq6ipU3GLMcIc
juj9/PGSr4w4ZaZu0Ytkkc66sRx5FCHhvomGn7i2FZvtEwQEc1suV/x6gNRlrLJn
XE/q9T8j/vGjSl8GuWI3
=UB4s
-----END PGP SIGNATURE-----
On 03/06/2015 11:23 AM, Ilya Kazakevich wrote:
> You may start from highest level testing:
> 1) create "usage scenarios" for your website. Like "customer opens page
> 'foo', and should see 'bar'". You use such scenarios for manual testing,
> right?
> 2) code such scenarios against Django project. You may use BDD testing
> tools (like lettuce or behave), or do it in pure python. You may call
> Django views and templates directly (using django unittesting support or
> lettuce/harvest), or do it through the browser using Selenium. One
> scenario -- one method. Yes, there is a lot of boilerplate code, but you
> only need to write it once. BDD tools are used to simplify this process
> by writing scenarios on DSL called Gherkin, which is easier.
>
> This is some kind of "acceptance testing", the one that helps you to be
> sure website works like customer expects it to work. Every project
> should have one, I believe.
>
> After it, you may find that some units of your system are complex and
> error prone. What is unit? Unit is module, function or even package with
> _clear interface_. You then create unit tests against this module. Only
> units with complex logic need to be tested. No need to test simple view
> that just returns render(): this view is tested as part of high level
> testing. But if you have function "calc_user_amount" and complex
> business logic stands behind it, you may create unit test for it.
>
> There are 3 mistakes people do about testing:
> 1) Testing each function, even private function, even 1 line function.
> It takes a lot of time, and such tests are fragile. You throw'em away
> after simple refactoring.
> 2) Testing "in the middle of abstraction": I mean testing functions with
> out of clear interface, like private functions. If you need to read
> function code before writing test (pydoc is not enough), you should not
> test this function. Try a higher level of abstraction.
> 3) Skipping high level testing: even if all your code is covered with
> low-level unit-tests, you still need high level testing like the one
> with Selenium to make sure everything works correctly, and when you
> refactor your code you use such testing to make sure you did not break
> anything.
>
> So, you start with high level, and then cover _some_ units with unit
> test, if you believe they may contain error.

This is really excellent advice.

Carl

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54F9FA6E.8050001%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.